Internet Documents

RFCs

RFCs All Documents

STDs Internet Standards Documents

BCPs Best Current Practice Documents

FYIs Informational Documents

RFC 1 Host Software

Authors: S. Crocker.

Date: April 1969

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0001

RFC 2 Host software

Authors: B. Duvall.

Date: April 1969

Formats: txt json html pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0002

RFC 3 Documentation conventions

Authors: S.D. Crocker.

Date: April 1969

Formats: txt json html

Obsoleted by: RFC 0010

Status: UNKNOWN

DOI: 10.17487/RFC 0003

RFC 4 Network timetable

Authors: E.B. Shapiro.

Date: March 1969

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0004

RFC 5 Decode Encode Language (DEL)

Authors: J. Rulifson.

Date: June 1969

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0005

RFC 6 Conversation with Bob Kahn

Authors: S.D. Crocker.

Date: April 1969

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0006

RFC 7 Host-IMP interface

Authors: G. Deloche.

Date: May 1969

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0007

RFC 8 ARPA Network Functional Specifications

Authors: G. Deloche.

Date: May 1969

Formats: pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0008

RFC 9 Host Software

Authors: G. Deloche.

Date: May 1969

Formats: pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0009

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 11 Implementation of the Host - Host Software Procedures in GORDO

Authors: G. Deloche.

Date: August 1969

Formats: txt json pdf html

Obsoleted by: RFC 0033

Status: UNKNOWN

DOI: 10.17487/RFC 0011

RFC 12 IMP-Host interface flow diagrams

Authors: M. Wingfield.

Date: August 1969

Formats: txt html pdf json ps

Status: UNKNOWN

DOI: 10.17487/RFC 0012

RFC 13 Zero Text Length EOF Message

Authors: V. Cerf.

Date: August 1969

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0013

RFC 15 Network subsystem for time sharing hosts

Authors: C.S. Carr.

Date: September 1969

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0015

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 17 Some questions re: Host-IMP Protocol

Authors: J.E. Kreznar.

Date: August 1969

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0017

RFC 18 IMP-IMP and HOST-HOST Control Links

Authors: V. Cerf.

Date: September 1969

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0018

RFC 19 Two protocol suggestions to reduce congestion at swap bound nodes

Authors: J.E. Kreznar.

Date: October 1969

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0019

RFC 20 ASCII format for network interchange

Authors: V.G. Cerf.

Date: October 1969

Formats: txt json pdf html

Also: STD 0080

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0020

RFC 21 Network meeting

Authors: V.G. Cerf.

Date: October 1969

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0021

RFC 22 Host-host control message formats

Authors: V.G. Cerf.

Date: October 1969

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0022

RFC 23 Transmission of Multiple Control Messages

Authors: G. Gregg.

Date: October 1969

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0023

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 25 No High Link Numbers

Authors: S.D. Crocker.

Date: October 1969

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0025

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 28 Time Standards

Authors: W.K. English.

Date: January 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0028

RFC 29 Response to RFC 28

Authors: R.E. Kahn.

Date: January 1970

Formats: txt json html

Also: RFC 0028

Status: UNKNOWN

DOI: 10.17487/RFC 0029

RFC 30 Documentation Conventions

Authors: S.D. Crocker.

Date: February 1970

Formats: txt json html

Updates: RFC 0010, RFC 0016, RFC 0024, RFC 0027

Status: UNKNOWN

DOI: 10.17487/RFC 0030

RFC 31 Binary Message Forms in Computer

Authors: D. Bobrow, W.R. Sutherland.

Date: February 1968

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0031

RFC 32 Some Thoughts on SRI's Proposed Real Time Clock

Authors: J. Cole.

Date: February 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0032

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 34 Some Brief Preliminary Notes on the Augmentation Research Center Clock

Authors: W.K. English.

Date: February 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0034

RFC 35 Network Meeting

Authors: S.D. Crocker.

Date: March 1970

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 0035

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 37 Network Meeting Epilogue, etc

Authors: S.D. Crocker.

Date: March 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0037

RFC 38 Comments on Network Protocol from NWG/RFC #36

Authors: S.M. Wolfe.

Date: March 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0038

RFC 39 Comments on Protocol Re: NWG/RFC #36

Authors: E. Harslem, J.F. Heafner.

Date: March 1970

Formats: txt json html

Updates: RFC 0036

Status: UNKNOWN

DOI: 10.17487/RFC 0039

RFC 40 More Comments on the Forthcoming Protocol

Authors: E. Harslem, J.F. Heafner.

Date: March 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0040

RFC 41 IMP-IMP Teletype Communication

Authors: J.T. Melvin.

Date: March 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0041

RFC 42 Message Data Types

Authors: E. Ancona.

Date: March 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0042

RFC 43 Proposed Meeting

Authors: A.G. Nemeth.

Date: April 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0043

RFC 44 Comments on NWG/RFC 33 and 36

Authors: A. Shoshani, R. Long, A. Landsberg.

Date: April 1970

Formats: txt html json

Updates: RFC 0036

Status: UNKNOWN

DOI: 10.17487/RFC 0044

RFC 45 New Protocol is Coming

Authors: J. Postel, S.D. Crocker.

Date: April 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0045

RFC 46 ARPA Network protocol notes

Authors: E. Meyer.

Date: April 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0046

RFC 47 BBN's Comments on NWG/RFC #33

Authors: J. Postel, S. Crocker.

Date: April 1970

Formats: txt json html

Updates: RFC 0033

Status: UNKNOWN

DOI: 10.17487/RFC 0047

RFC 48 Possible protocol plateau

Authors: J. Postel, S.D. Crocker.

Date: April 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0048

RFC 49 Conversations with S. Crocker (UCLA)

Authors: Crocker (UCLA). E. Meyer.

Date: April 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0049

RFC 50 Comments on the Meyer Proposal

Authors: E. Harslen, J. Heafner.

Date: April 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0050

RFC 51 Proposal for a Network Interchange Language

Authors: M. Elie.

Date: May 1970

Formats: pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0051

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 53 Official protocol mechanism

Authors: S.D. Crocker.

Date: June 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0053

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 55 Prototypical implementation of the NCP

Authors: J. Newkirk, M. Kraley, J. Postel, S.D. Crocker.

Date: June 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0055

RFC 56 Third Level Protocol: Logger Protocol

Authors: E. Belove, D. Black, R. Flegal, L.G. Farquar.

Date: June 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0056

RFC 57 Thoughts and Reflections on NWG/RFC 54

Authors: M. Kraley, J. Newkirk.

Date: June 1970

Formats: txt json html

Updates: RFC 0054

Status: UNKNOWN

DOI: 10.17487/RFC 0057

RFC 58 Logical Message Synchronization

Authors: T.P. Skinner.

Date: June 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0058

RFC 59 Flow Control - Fixed Versus Demand Allocation

Authors: E. Meyer.

Date: June 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0059

RFC 60 A Simplified NCP Protocol

Authors: R. Kalin.

Date: July 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0060

This RFC defines a new NCP protocol that is simple enough to be implemented on a very small computer, yet can be extended for efficient operation on large timesharing machines. Because worst case storage requirements can be predicted, a conservative implementation can be freed of complicated resource allocation and storage control procedures. A general error recovery procedure is also defined.

RFC 61 Note on Interprocess Communication in a Resource Sharing Computer Network

Authors: D.C. Walden.

Date: July 1970

Formats: txt html json

Obsoleted by: RFC 0062

Status: UNKNOWN

DOI: 10.17487/RFC 0061

RFC 62 Systems for Interprocess Communication in a Resource Sharing Computer Network

Authors: D.C. Walden.

Date: August 1970

Formats: txt json html

Obsoletes: RFC 0061

Status: UNKNOWN

DOI: 10.17487/RFC 0062

RFC 63 Belated Network Meeting Report

Authors: V.G. Cerf.

Date: July 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0063

RFC 64 Getting rid of marking

Authors: M. Elie.

Date: July 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0064

RFC 65 Comments on Host/Host Protocol document #1

Authors: D.C. Walden.

Date: August 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0065

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 67 Proposed Change to Host/IMP Spec to Eliminate Marking

Authors: W.R. Crowther.

Date: January 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0067

RFC 68 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM

Authors: M. Elie.

Date: August 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0068

RFC 69 Distribution List Change for MIT

Authors: A.K. Bhushan.

Date: September 1970

Formats: txt html json

Updates: RFC 0052

Status: UNKNOWN

DOI: 10.17487/RFC 0069

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 71 Reallocation in Case of Input Error

Authors: T. Schipper.

Date: September 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0071

RFC 72 Proposed Moratorium on Changes to Network Protocol

Authors: R.D. Bressler.

Date: September 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0072

RFC 73 Response to NWG/RFC 67

Authors: S.D. Crocker.

Date: September 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0073

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 75 Network Meeting

Authors: S.D. Crocker.

Date: October 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0075

RFC 76 Connection by name: User oriented protocol

Authors: J. Bouknight, J. Madden, G.R. Grossman.

Date: October 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0076

RFC 77 Network meeting report

Authors: J. Postel.

Date: November 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0077

RFC 78 NCP Status Report: UCSB/Rand

Authors: E. Harslem, J.F. Heafner, J.E. White.

Date: October 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0078

RFC 79 Logger Protocol error

Authors: E. Meyer.

Date: November 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0079

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 81 Request for Reference Information

Authors: J. Bouknight.

Date: December 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0081

RFC 82 Network Meeting Notes

Authors: E. Meyer.

Date: December 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0082

RFC 83 Language-machine for data reconfiguration

Authors: R.H. Anderson, E. Harslem, J.F. Heafner.

Date: December 1970

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0083

RFC 84 List of NWG/RFC's 1-80

Authors: J.B. North.

Date: December 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0084

RFC 85 Network Working Group meeting

Authors: S.D. Crocker.

Date: December 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0085

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 87 Topic for Discussion at the Next Network Working Group Meeting

Authors: A. Vezza.

Date: January 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0087

RFC 88 NETRJS: A third level protocol for Remote Job Entry

Authors: R.T. Braden, S.M. Wolfe.

Date: January 1971

Formats: txt html json

Obsoleted by: RFC 0189

Status: UNKNOWN

DOI: 10.17487/RFC 0088

RFC 89 Some historic moments in networking

Authors: R.M. Metcalfe.

Date: January 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0089

RFC 90 CCN as a Network Service Center

Authors: R.T. Braden.

Date: January 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0090

RFC 91 Proposed User-User Protocol

Authors: G.H. Mealy.

Date: December 1970

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0091

RFC 93 Initial Connection Protocol

Authors: A.M. McKenzie.

Date: January 1971

Formats: txt json html

Updates: RFC 0066, RFC 0080

Status: UNKNOWN

DOI: 10.17487/RFC 0093

RFC 94 Some thoughts on Network Graphics

Authors: E. Harslem, J.F. Heafner.

Date: February 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0094

RFC 95 Distribution of NWG/RFC's through the NIC

Authors: S. Crocker.

Date: February 1971

Formats: txt html json

Obsoleted by: RFC 0155

Status: UNKNOWN

DOI: 10.17487/RFC 0095

RFC 96 An Interactive Network Experiment to Study Modes of Access the Network Information Center

Authors: R.W. Watson.

Date: February 1971

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 0096

RFC 97 First Cut at a Proposed Telnet Protocol

Authors: J.T. Melvin, R.W. Watson.

Date: February 1971

Formats: txt json html pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0097

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 100 Categorization and guide to NWG/RFCs

Authors: P.M. Karp.

Date: February 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0100

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 103 Implementation of Interrupt Keys

Authors: R.B. Kalin.

Date: February 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0103

RFC 104 Link 191

Authors: J.B. Postel, S.D. Crocker.

Date: February 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0104

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 106 User/Server Site Protocol Network Host Questionnaire

Authors: T.C. O'Sullivan.

Date: March 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0106

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 108 Attendance list at the Urbana NWG meeting, February 17-19, 1971

Authors: R.W. Watson.

Date: March 1971

Formats: txt json html

Updates: RFC 0101

Status: UNKNOWN

DOI: 10.17487/RFC 0108

RFC 109 Level III Server Protocol for the Lincoln Laboratory 360/67 Host

Authors: J. Winett.

Date: March 1971

Formats: txt json pdf html

Also: RFC 0393

Status: UNKNOWN

DOI: 10.17487/RFC 0109

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 112 User/Server Site Protocol: Network Host Questionnaire

Authors: T.C. O'Sullivan.

Date: April 1971

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0112

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 115 Some Network Information Center policies on handling documents

Authors: R.W. Watson, J.B. North.

Date: April 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0115

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 117 Some comments on the official protocol

Authors: J. Wong.

Date: April 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0117

RFC 118 Recommendations for facility documentation

Authors: R.W. Watson.

Date: April 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0118

RFC 119 Network Fortran Subprograms

Authors: M. Krilanovich.

Date: April 1971

Formats: txt pdf json html

Status: UNKNOWN

DOI: 10.17487/RFC 0119

RFC 120 Network PL1 subprograms

Authors: M. Krilanovich.

Date: April 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0120

RFC 121 Network on-line operators

Authors: M. Krilanovich.

Date: April 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0121

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 124 Typographical error in RFC 107

Authors: J.T. Melvin.

Date: April 1971

Formats: txt json html

Updates: RFC 0107

Status: UNKNOWN

DOI: 10.17487/RFC 0124

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 126 Graphics Facilities at Ames Research Center

Authors: J. McConnell.

Date: April 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0126

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 128 Bytes

Authors: J. Postel.

Date: April 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0128

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 130 Response to RFC 111: Pressure from the chairman

Authors: J.F. Heafner.

Date: April 1971

Formats: txt json html

Updates: RFC 0111

Status: UNKNOWN

DOI: 10.17487/RFC 0130

RFC 131 Response to RFC 116: May NWG meeting

Authors: E. Harslem, J.F. Heafner.

Date: April 1971

Formats: txt json html

Updates: RFC 0116

Status: UNKNOWN

DOI: 10.17487/RFC 0131

RFC 132 Typographical Error in RFC 107

Authors: J.E. White.

Date: April 1971

Formats: txt html json

Obsoleted by: RFC 0154

Updates: RFC 0107

Status: UNKNOWN

DOI: 10.17487/RFC 0132

RFC 133 File Transfer and Error Recovery

Authors: R.L. Sunberg.

Date: April 1971

Formats: txt html json

Updates: RFC 0114

Status: UNKNOWN

DOI: 10.17487/RFC 0133

RFC 134 Network Graphics meeting

Authors: A. Vezza.

Date: April 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0134

RFC 135 Response to NWG/RFC 110

Authors: W. Hathaway.

Date: April 1971

Formats: txt json html

Updates: RFC 0110

Status: UNKNOWN

DOI: 10.17487/RFC 0135

RFC 136 Host accounting and administrative procedures

Authors: R.E. Kahn.

Date: April 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0136

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 138 Status report on proposed Data Reconfiguration Service

Authors: R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood.

Date: April 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0138

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 141 Comments on RFC 114: A File Transfer Protocol

Authors: E. Harslem, J.F. Heafner.

Date: April 1971

Formats: txt html json

Updates: RFC 0114

Status: UNKNOWN

DOI: 10.17487/RFC 0141

RFC 142 Time-Out Mechanism in the Host-Host Protocol

Authors: C. Kline, J. Wong.

Date: May 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0142

RFC 143 Regarding proffered official ICP

Authors: W. Naylor, J. Wong, C. Kline, J. Postel.

Date: May 1971

Formats: txt json html

Obsoleted by: RFC 0165

Updates: RFC 0123, RFC 0145

Status: UNKNOWN

DOI: 10.17487/RFC 0143

RFC 144 Data sharing on computer networks

Authors: A. Shoshani.

Date: April 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0144

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 146 Views on issues relevant to data sharing on computer networks

Authors: P.M. Karp, D.B. McKay, D.C.M. Wood.

Date: May 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0146

RFC 147 Definition of a socket

Authors: J.M. Winett.

Date: May 1971

Formats: txt json html

Updates: RFC 0129

Status: UNKNOWN

DOI: 10.17487/RFC 0147

RFC 148 Comments on RFC 123

Authors: A.K. Bhushan.

Date: May 1971

Formats: txt html json

Updates: RFC 0123

Status: UNKNOWN

DOI: 10.17487/RFC 0148

RFC 149 Best Laid Plans

Authors: S.D. Crocker.

Date: May 1971

Formats: txt html json

Updates: RFC 0140

Status: UNKNOWN

DOI: 10.17487/RFC 0149

RFC 150 Use of IPC Facilities: A Working Paper

Authors: R.B. Kalin.

Date: May 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0150

RFC 151 Comments on a proffered official ICP: RFCs 123, 127

Authors: A. Shoshani.

Date: May 1971

Formats: txt html json

Updates: RFC 0127

Status: UNKNOWN

DOI: 10.17487/RFC 0151

RFC 152 SRI Artificial Intelligence status report

Authors: M. Wilber.

Date: May 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0152

RFC 153 SRI ARC-NIC status

Authors: J.T. Melvin, R.W. Watson.

Date: May 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0153

RFC 154 Exposition Style

Authors: S.D. Crocker.

Date: May 1971

Formats: txt html json

Obsoletes: RFC 0132

Updates: RFC 0107

Status: UNKNOWN

DOI: 10.17487/RFC 0154

RFC 155 ARPA Network mailing lists

Authors: J.B. North.

Date: May 1971

Formats: txt html json

Obsoletes: RFC 0095

Obsoleted by: RFC 0168

Status: UNKNOWN

DOI: 10.17487/RFC 0155

RFC 156 Status of the Illinois site: Response to RFC 116

Authors: J. Bouknight.

Date: April 1971

Formats: txt json html

Updates: RFC 0116

Status: UNKNOWN

DOI: 10.17487/RFC 0156

RFC 157 Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems

Authors: V.G. Cerf.

Date: May 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0157

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 160 RFC brief list

Authors: Network Information Center. Stanford Research Institute.

Date: May 1971

Formats: txt html json

Obsoleted by: RFC 0200, RFC 0999

Updates: NIC_6716

Status: UNKNOWN

DOI: 10.17487/RFC 0160

RFC 161 Solution to the race condition in the ICP

Authors: A. Shoshani.

Date: May 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0161

RFC 162 NETBUGGER3

Authors: M. Kampe.

Date: May 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0162

RFC 163 Data transfer protocols

Authors: V.G. Cerf.

Date: May 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0163

RFC 164 Minutes of Network Working Group meeting, 5/16 through 5/19/71

Authors: J.F. Heafner.

Date: May 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0164

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 166 Data Reconfiguration Service: An implementation specification

Authors: R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood.

Date: May 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0166

RFC 167 Socket conventions reconsidered

Authors: A.K. Bhushan, R.M. Metcalfe, J.M. Winett.

Date: May 1971

Formats: txt json html

Also: RFC 0129, RFC 0147

Status: UNKNOWN

DOI: 10.17487/RFC 0167

RFC 168 ARPA Network mailing lists

Authors: J.B. North.

Date: May 1971

Formats: txt html json

Obsoletes: RFC 0155

Obsoleted by: RFC 0211

Status: UNKNOWN

DOI: 10.17487/RFC 0168

RFC 169 COMPUTER NETWORKS

Authors: S.D. Crocker.

Date: May 1971

Formats: txt html json pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0169

RFC 170 RFC List by Number

Authors: Network Information Center. Stanford Research Institute.

Date: June 1971

Formats: txt html json

Obsoleted by: RFC 0200

Status: UNKNOWN

DOI: 10.17487/RFC 0170

RFC 171 The Data Transfer Protocol

Authors: A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D. Watson, J. White.

Date: June 1971

Formats: txt html json

Obsoleted by: RFC 0264

Updates: RFC 0114

Updated by: RFC 0238

Status: UNKNOWN

DOI: 10.17487/RFC 0171

RFC 172 The File Transfer Protocol

Authors: A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White.

Date: June 1971

Formats: txt json html

Obsoleted by: RFC 0265

Updates: RFC 0114

Updated by: RFC 0238

Status: UNKNOWN

DOI: 10.17487/RFC 0172

RFC 173 Network Data Management Committee Meeting Announcement

Authors: P.M. Karp, D.B. McKay.

Date: June 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0173

RFC 174 UCLA - Computer Science Graphics Overview

Authors: J. Postel, V.G. Cerf.

Date: June 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0174

RFC 175 Comments on "Socket Conventions Reconsidered"

Authors: E. Harslem, J.F. Heafner.

Date: June 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0175

RFC 176 Comments on "Byte size for connections"

Authors: A.K. Bhushan, R. Kanodia, R.M. Metcalfe, J. Postel.

Date: June 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0176

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 178 Network graphic attention handling

Authors: I.W. Cotton.

Date: June 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0178

RFC 179 Link Number Assignments

Authors: A.M. McKenzie.

Date: June 1971

Formats: txt html json

Updates: RFC 0107

Status: UNKNOWN

DOI: 10.17487/RFC 0179

RFC 180 File system questionnaire

Authors: A.M. McKenzie.

Date: June 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0180

RFC 181 Modifications to RFC 177

Authors: J. McConnell.

Date: July 1971

Formats: txt html json

Updates: RFC 0177

Status: UNKNOWN

DOI: 10.17487/RFC 0181

RFC 182 Compilation of list of relevant site reports

Authors: J.B. North.

Date: June 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0182

RFC 183 EBCDIC Codes and Their Mapping to ASCII

Authors: J.M. Winett.

Date: July 1971

Formats: txt json pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0183

The uniquely map the ASCII codes into corresponding EBCDIC codes in a consistent manner throughout the ARPA Network, this RFC describes and defines the IBM Standard Extended BCD Interchanged Code.

RFC 184 Proposed graphic display modes

Authors: K.C. Kelley.

Date: July 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0184

RFC 185 NIC distribution of manuals and handbooks

Authors: J.B. North.

Date: July 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0185

RFC 186 Network graphics loader

Authors: J.C. Michener.

Date: July 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0186

RFC 187 Network/440 Protocol Concept

Authors: D.B. McKay, D.P. Karp.

Date: July 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0187

RFC 188 Data management meeting announcement

Authors: P.M. Karp, D.B. McKay.

Date: January 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0188

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 190 DEC PDP-10-IMLAC communications system

Authors: L.P. Deutsch.

Date: July 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0190

RFC 191 Graphics implementation and conceptualization at Augmentation Research Center

Authors: C.H. Irby.

Date: July 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0191

RFC 192 Some factors which a Network Graphics Protocol must consider

Authors: R.W. Watson.

Date: July 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0192

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 194 The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes

Authors: V. Cerf, E. Harslem, J. Heafner, B. Metcalfe, J. White.

Date: July 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0194

RFC 195 Data computers-data descriptions and access language

Authors: G.H. Mealy.

Date: July 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0195

RFC 196 Mail Box Protocol

Authors: R.W. Watson.

Date: July 1971

Formats: txt json html

Obsoleted by: RFC 0221

Status: UNKNOWN

DOI: 10.17487/RFC 0196

RFC 197 Initial Connection Protocol - Reviewed

Authors: A. Shoshani, E. Harslem.

Date: July 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0197

RFC 198 Site Certification - Lincoln Labs 360/67

Authors: J.F. Heafner.

Date: July 1971

Formats: txt html json

Obsoletes: RFC 0193

Obsoleted by: RFC 0214

Updates: RFC 0193

Status: UNKNOWN

DOI: 10.17487/RFC 0198

RFC 199 Suggestions for a Network Data-Tablet Graphics Protocol

Authors: T. Williams.

Date: July 1971

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0199

RFC 200 RFC list by number

Authors: J.B. North.

Date: August 1971

Formats: txt html json

Obsoletes: RFC 0170, RFC 0160

Obsoleted by: NIC_7724

Status: UNKNOWN

DOI: 10.17487/RFC 0200

RFC 202 Possible Deadlock in ICP

Authors: S.M. Wolfe, J. Postel.

Date: July 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0202

RFC 203 Achieving reliable communication

Authors: R.B. Kalin.

Date: August 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0203

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 205 NETCRT - a character display protocol

Authors: R.T. Braden.

Date: August 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0205

RFC 206 A User TELNET Description of an Initial Implementation

Authors: J. White.

Date: August 1971

Formats: txt json pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0206

RFC 207 September Network Working Group meeting

Authors: A. Vezza.

Date: August 1971

Formats: txt json html

Obsoleted by: RFC 0212

Status: UNKNOWN

DOI: 10.17487/RFC 0207

RFC 208 Address tables

Authors: A.M. McKenzie.

Date: August 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0208

RFC 209 Host/IMP interface documentation

Authors: B. Cosell.

Date: August 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0209

RFC 210 Improvement of Flow Control

Authors: W. Conrad.

Date: August 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0210

RFC 211 ARPA Network Mailing Lists

Authors: J.B. North.

Date: August 1971

Formats: txt pdf html json

Obsoletes: RFC 0168

Obsoleted by: RFC 0300

Status: UNKNOWN

DOI: 10.17487/RFC 0211

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 213 IMP System change notification

Authors: B. Cosell.

Date: August 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0213

RFC 214 Network checkpoint

Authors: E. Harslem.

Date: August 1971

Formats: txt html json

Obsoletes: RFC 0198

Status: UNKNOWN

DOI: 10.17487/RFC 0214

RFC 215 NCP, ICP, and Telnet: The Terminal IMP implementation

Authors: A.M. McKenzie.

Date: August 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0215

RFC 216 Telnet Access to UCSB's On-Line System

Authors: J.E. White.

Date: September 1971

Formats: txt json pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0216

RFC 217 Specifications changes for OLS, RJE/RJOR, and SMFS

Authors: J.E. White.

Date: September 1971

Formats: txt json html

Updates: RFC 0074, RFC 0105, RFC 0122

Status: UNKNOWN

DOI: 10.17487/RFC 0217

RFC 218 Changing the IMP status reporting facility

Authors: B. Cosell.

Date: September 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0218

RFC 219 User's View of the Datacomputer

Authors: R. Winter.

Date: September 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0219

RFC 221 Mail Box Protocol: Version 2

Authors: R.W. Watson.

Date: August 1971

Formats: txt html json

Obsoletes: RFC 0196

Obsoleted by: RFC 0278

Status: UNKNOWN

DOI: 10.17487/RFC 0221

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 223 Network Information Center schedule for network users

Authors: J.T. Melvin, R.W. Watson.

Date: September 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0223

RFC 224 Comments on Mailbox Protocol

Authors: A.M. McKenzie.

Date: September 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0224

RFC 225 Rand/UCSB network graphics experiment

Authors: E. Harslem, R. Stoughton.

Date: September 1971

Formats: txt html json

Updates: RFC 0074

Status: UNKNOWN

DOI: 10.17487/RFC 0225

RFC 226 Standardization of host mnemonics

Authors: P.M. Karp.

Date: September 1971

Formats: txt json html

Obsoleted by: RFC 0247

Status: UNKNOWN

DOI: 10.17487/RFC 0226

RFC 227 Data transfer rates (Rand/UCLA)

Authors: J.F. Heafner, E. Harslem.

Date: September 1971

Formats: txt json html

Updates: RFC 0113

Status: UNKNOWN

DOI: 10.17487/RFC 0227

RFC 228 Clarification

Authors: D.C. Walden.

Date: September 1971

Formats: txt html json

Updates: RFC 0070

Status: UNKNOWN

DOI: 10.17487/RFC 0228

RFC 229 Standard host names

Authors: J. Postel.

Date: September 1971

Formats: txt html json

Obsoleted by: RFC 0236

Status: UNKNOWN

DOI: 10.17487/RFC 0229

RFC 230 Toward reliable operation of minicomputer-based terminals on a TIP

Authors: T. Pyke.

Date: September 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0230

RFC 231 Service center standards for remote usage: A user's view

Authors: J.F. Heafner, E. Harslem.

Date: September 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0231

RFC 232 Postponement of network graphics meeting

Authors: A. Vezza.

Date: September 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0232

RFC 233 Standardization of host call letters

Authors: A. Bhushan, R. Metcalfe.

Date: September 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0233

RFC 234 Network Working Group meeting schedule

Authors: A. Vezza.

Date: October 1971

Formats: txt html json

Updates: RFC 0222, RFC 0204

Status: UNKNOWN

DOI: 10.17487/RFC 0234

RFC 235 Site status

Authors: E. Westheimer.

Date: September 1971

Formats: txt html json

Obsoleted by: RFC 0240

Status: UNKNOWN

DOI: 10.17487/RFC 0235

RFC 236 Standard host names

Authors: J. Postel.

Date: September 1971

Formats: txt json html

Obsoletes: RFC 0229

Status: UNKNOWN

DOI: 10.17487/RFC 0236

RFC 237 NIC view of standard host names

Authors: R.W. Watson.

Date: October 1971

Formats: txt json html

Obsoleted by: RFC 0273

Status: UNKNOWN

DOI: 10.17487/RFC 0237

RFC 238 Comments on DTP and FTP proposals

Authors: R.T. Braden.

Date: September 1971

Formats: txt html json

Updates: RFC 0171, RFC 0172

Status: UNKNOWN

DOI: 10.17487/RFC 0238

RFC 239 Host mnemonics proposed in RFC 226 (NIC 7625)

Authors: R.T. Braden.

Date: September 1971

Formats: txt html json

Also: RFC 0226, RFC 0229, RFC 0236

Status: UNKNOWN

DOI: 10.17487/RFC 0239

RFC 240 Site Status

Authors: A.M. McKenzie.

Date: September 1971

Formats: txt json html

Obsoletes: RFC 0235

Obsoleted by: RFC 0252

Status: UNKNOWN

DOI: 10.17487/RFC 0240

RFC 241 Connecting computers to MLC ports

Authors: A.M. McKenzie.

Date: September 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0241

RFC 242 Data Descriptive Language for Shared Data

Authors: L. Haibt, A.P. Mullery.

Date: July 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0242

RFC 243 Network and data sharing bibliography

Authors: A.P. Mullery.

Date: October 1971

Formats: txt html json

Obsoleted by: RFC 0290

Status: UNKNOWN

DOI: 10.17487/RFC 0243

RFC 245 Reservations for Network Group meeting

Authors: C. Falls.

Date: October 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0245

RFC 246 Network Graphics meeting

Authors: A. Vezza.

Date: October 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0246

RFC 247 Proffered set of standard host names

Authors: P.M. Karp.

Date: October 1971

Formats: txt html json

Obsoletes: RFC 0226

Status: UNKNOWN

DOI: 10.17487/RFC 0247

RFC 249 Coordination of equipment and supplies purchase

Authors: R.F. Borelli.

Date: October 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0249

RFC 250 Some thoughts on file transfer

Authors: H. Brodie.

Date: October 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0250

RFC 251 Weather data

Authors: D. Stern.

Date: October 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0251

RFC 252 Network host status

Authors: E. Westheimer.

Date: October 1971

Formats: txt html json

Obsoletes: RFC 0240

Obsoleted by: RFC 0255

Status: UNKNOWN

DOI: 10.17487/RFC 0252

RFC 253 Second Network Graphics meeting details

Authors: J.A. Moorer.

Date: October 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0253

RFC 254 Scenarios for using ARPANET computers

Authors: A. Bhushan.

Date: October 1971

Formats: txt json html pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0254

RFC 255 Status of network hosts

Authors: E. Westheimer.

Date: October 1971

Formats: txt json html

Obsoletes: RFC 0252

Obsoleted by: RFC 0266

Status: UNKNOWN

DOI: 10.17487/RFC 0255

RFC 256 IMPSYS change notification

Authors: B. Cosell.

Date: November 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0256

RFC 263 "Very Distant" Host interface

Authors: A.M. McKenzie.

Date: December 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0263

RFC 264 The Data Transfer Protocol

Authors: A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J. White.

Date: January 1972

Formats: txt json html

Obsoletes: RFC 0171

Obsoleted by: RFC 0354

Updated by: RFC 0310

Also: RFC 0265

Status: UNKNOWN

DOI: 10.17487/RFC 0264

RFC 265 The File Transfer Protocol

Authors: A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White.

Date: November 1971

Formats: txt json html

Obsoletes: RFC 0172

Obsoleted by: RFC 0354

Updated by: RFC 0281, RFC 0294, RFC 0310

Also: RFC 0264

Status: UNKNOWN

DOI: 10.17487/RFC 0265

RFC 266 Network host status

Authors: E. Westheimer.

Date: November 1971

Formats: txt html json

Obsoletes: RFC 0255

Obsoleted by: RFC 0267

Status: UNKNOWN

DOI: 10.17487/RFC 0266

RFC 267 Network Host Status

Authors: E. Westheimer.

Date: November 1971

Formats: txt html json

Obsoletes: RFC 0266

Obsoleted by: RFC 0287

Status: UNKNOWN

DOI: 10.17487/RFC 0267

RFC 268 Graphics facilities information

Authors: J. Postel.

Date: November 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0268

RFC 269 Some Experience with File Transfer

Authors: H. Brodie.

Date: December 1971

Formats: txt json html

Updates: RFC 0122

Status: UNKNOWN

DOI: 10.17487/RFC 0269

RFC 270 Correction to BBN Report No. 1822 (NIC NO 7958)

Authors: A.M. McKenzie.

Date: January 1972

Formats: txt json pdf html

Updates: NIC_7959

Status: UNKNOWN

DOI: 10.17487/RFC 0270

RFC 271 IMP System change notifications

Authors: B. Cosell.

Date: January 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0271

RFC 273 More on standard host names

Authors: R.W. Watson.

Date: October 1971

Formats: txt html json

Obsoletes: RFC 0237

Status: UNKNOWN

DOI: 10.17487/RFC 0273

RFC 274 Establishing a local guide for network usage

Authors: E. Forman.

Date: November 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0274

RFC 276 NIC course

Authors: R.W. Watson.

Date: November 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0276

RFC 278 Revision of the Mail Box Protocol

Authors: A.K. Bhushan, R.T. Braden, E. Harslem, J.F. Heafner, A.M. McKenzie, J.T. Melvin, R.L. Sundberg, R.W. Watson, J.E. White.

Date: November 1971

Formats: txt json html

Obsoletes: RFC 0221

Status: UNKNOWN

DOI: 10.17487/RFC 0278

RFC 280 A Draft of Host Names

Authors: R.W. Watson.

Date: November 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0280

RFC 281 Suggested addition to File Transfer Protocol

Authors: A.M. McKenzie.

Date: December 1971

Formats: txt json html

Updates: RFC 0265

Status: UNKNOWN

DOI: 10.17487/RFC 0281

RFC 282 Graphics meeting report

Authors: M.A. Padlipsky.

Date: December 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0282

RFC 283 NETRJT: Remote Job Service Protocol for TIPS

Authors: R.T. Braden.

Date: December 1971

Formats: txt html json

Updates: RFC 0189

Status: UNKNOWN

DOI: 10.17487/RFC 0283

RFC 285 Network graphics

Authors: D. Huff.

Date: December 1971

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0285

RFC 286 Network Library Information System

Authors: E. Forman.

Date: December 1971

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0286

RFC 287 Status of Network Hosts

Authors: E. Westheimer.

Date: December 1971

Formats: txt html json

Obsoletes: RFC 0267

Obsoleted by: RFC 0288

Status: UNKNOWN

DOI: 10.17487/RFC 0287

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 289 What we hope is an official list of host names

Authors: R.W. Watson.

Date: December 1971

Formats: txt json html

Obsoleted by: RFC 0384

Status: UNKNOWN

DOI: 10.17487/RFC 0289

RFC 290 Computer networks and data sharing: A bibliography

Authors: A.P. Mullery.

Date: January 1972

Formats: txt json html

Obsoletes: RFC 0243

Status: UNKNOWN

DOI: 10.17487/RFC 0290

RFC 291 Data Management Meeting Announcement

Authors: D.B. McKay.

Date: January 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0291

RFC 292 Graphics Protocol: Level 0 only

Authors: J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. Liddle, E. Meyer.

Date: January 1972

Formats: txt html json

Obsoleted by: RFC 0493

Status: UNKNOWN

DOI: 10.17487/RFC 0292

RFC 293 Network Host Status

Authors: E. Westheimer.

Date: January 1972

Formats: txt html json

Obsoletes: RFC 0288

Obsoleted by: RFC 0298

Updates: RFC 0288

Status: UNKNOWN

DOI: 10.17487/RFC 0293

RFC 294 The Use of "Set Data Type" Transaction in File Transfer Protocol

Authors: A.K. Bhushan.

Date: January 1972

Formats: txt json html

Updates: RFC 0265

Status: UNKNOWN

DOI: 10.17487/RFC 0294

RFC 295 Report of the Protocol Workshop, 12 October 1971

Authors: J. Postel.

Date: January 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0295

RFC 296 DS-1 Display System

Authors: D.E. Liddle.

Date: January 1972

Formats: txt pdf html json

Status: UNKNOWN

DOI: 10.17487/RFC 0296

RFC 297 TIP Message Buffers

Authors: D.C. Walden.

Date: January 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0297

RFC 298 Network host status

Authors: E. Westheimer.

Date: February 1972

Formats: txt json html

Obsoletes: RFC 0293

Obsoleted by: RFC 0306

Status: UNKNOWN

DOI: 10.17487/RFC 0298

RFC 299 Information Management System

Authors: D. Hopkin.

Date: February 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0299

RFC 300 ARPA Network mailing lists

Authors: J.B. North.

Date: January 1972

Formats: txt json html

Obsoletes: RFC 0211

Obsoleted by: RFC 0303

Status: UNKNOWN

DOI: 10.17487/RFC 0300

RFC 301 BBN IMP (#5) and NCC Schedule March 4, 1971

Authors: R. Alter.

Date: February 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0301

RFC 302 Exercising The ARPANET

Authors: R.F. Bryan.

Date: February 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0302

RFC 303 ARPA Network mailing lists

Authors: Network Information Center. Stanford Research Institute.

Date: March 1972

Formats: txt html json

Obsoletes: RFC 0300

Obsoleted by: RFC 0329

Status: UNKNOWN

DOI: 10.17487/RFC 0303

RFC 304 Data Management System Proposal for the ARPA Network

Authors: D.B. McKay.

Date: February 1972

Formats: txt json pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0304

RFC 305 Unknown Host Numbers

Authors: R. Alter.

Date: February 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0305

RFC 306 Network host status

Authors: E. Westheimer.

Date: February 1972

Formats: txt html json

Obsoletes: RFC 0298

Obsoleted by: RFC 0315

Status: UNKNOWN

DOI: 10.17487/RFC 0306

RFC 307 Using network Remote Job Entry

Authors: E. Harslem.

Date: February 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0307

RFC 308 ARPANET host availability data

Authors: M. Seriff.

Date: March 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0308

RFC 309 Data and File Transfer Workshop Announcement

Authors: A.K. Bhushan.

Date: March 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0309

RFC 310 Another Look at Data and File Transfer Protocols

Authors: A.K. Bhushan.

Date: April 1972

Formats: txt json html

Updates: RFC 0264, RFC 0265

Status: UNKNOWN

DOI: 10.17487/RFC 0310

RFC 311 New Console Attachments to the USCB Host

Authors: R.F. Bryan.

Date: February 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0311

RFC 312 Proposed Change in IMP-to-Host Protocol

Authors: A.M. McKenzie.

Date: March 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0312

RFC 313 Computer based instruction

Authors: T.C. O'Sullivan.

Date: March 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0313

RFC 314 Network Graphics Working Group Meeting

Authors: I.W. Cotton.

Date: March 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0314

RFC 315 Network Host Status

Authors: E. Westheimer.

Date: March 1972

Formats: txt json html

Obsoletes: RFC 0306

Obsoleted by: RFC 0319

Status: UNKNOWN

DOI: 10.17487/RFC 0315

RFC 316 ARPA Network Data Management Working Group

Authors: D.B. McKay, A.P. Mullery.

Date: February 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0316

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. [STANDARDS TRACK

RFC 317 Official Host-Host Protocol Modification: Assigned Link Numbers

Authors: J. Postel.

Date: March 1972

Formats: txt html json

Obsoleted by: RFC 0604

Status: UNKNOWN

DOI: 10.17487/RFC 0317

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 320 Workshop on Hard Copy Line Graphics

Authors: R. Reddy.

Date: March 1972

Formats: txt json html pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0320

RFC 321 CBI Networking Activity at MITRE

Authors: P.M. Karp.

Date: March 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0321

RFC 322 Well known socket numbers

Authors: V. Cerf, J. Postel.

Date: March 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0322

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 324 RJE Protocol meeting

Authors: J. Postel.

Date: April 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0324

RFC 325 Network Remote Job Entry program - NETRJS

Authors: G. Hicks.

Date: April 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0325

RFC 326 Network Host Status

Authors: E. Westheimer.

Date: April 1972

Formats: txt html json

Obsoleted by: RFC 0330

Updates: RFC 0319

Status: UNKNOWN

DOI: 10.17487/RFC 0326

RFC 327 Data and File Transfer workshop notes

Authors: A.K. Bhushan.

Date: April 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0327

RFC 328 Suggested Telnet Protocol Changes

Authors: J. Postel.

Date: April 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0328

RFC 329 ARPA Network Mailing Lists

Authors: Network Information Center. Stanford Research Institute.

Date: May 1972

Formats: txt json html

Obsoletes: RFC 0303

Obsoleted by: RFC 0363

Status: UNKNOWN

DOI: 10.17487/RFC 0329

RFC 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 331 IMP System Change Notification

Authors: J.M. McQuillan.

Date: April 1972

Formats: txt json html

Obsoleted by: RFC 0343

Status: UNKNOWN

DOI: 10.17487/RFC 0331

RFC 332 Network Host Status

Authors: E. Westheimer.

Date: April 1972

Formats: txt html json

Obsoleted by: RFC 0342

Updates: RFC 0330

Status: UNKNOWN

DOI: 10.17487/RFC 0332

RFC 333 Proposed experiment with a Message Switching Protocol

Authors: R.D. Bressler, D. Murphy, D.C. Walden.

Date: May 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0333

RFC 334 Network Use on May 8

Authors: A.M. McKenzie.

Date: May 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0334

RFC 335 New Interface - IMP/360

Authors: R.F. Bryan.

Date: May 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0335

RFC 336 Level 0 Graphic Input Protocol

Authors: I.W. Cotton.

Date: May 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0336

RFC 338 EBCDIC/ASCII Mapping for Network RJE

Authors: R.T. Braden.

Date: May 1972

Formats: txt json html pdf ps

Status: UNKNOWN

DOI: 10.17487/RFC 0338

RFC 339 MLTNET: A "Multi Telnet" Subsystem for Tenex

Authors: R. Thomas.

Date: May 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0339

RFC 340 Proposed Telnet Changes

Authors: T.C. O'Sullivan.

Date: May 1972

Formats: txt html json

Also: RFC 0328

Status: UNKNOWN

DOI: 10.17487/RFC 0340

RFC 342 Network Host Status

Authors: E. Westheimer.

Date: May 1972

Formats: txt json html

Obsoletes: RFC 0332

Obsoleted by: RFC 0344

Status: UNKNOWN

DOI: 10.17487/RFC 0342

RFC 343 IMP System change notification

Authors: A.M. McKenzie.

Date: May 1972

Formats: txt json html

Obsoletes: RFC 0331

Obsoleted by: RFC 0359

Status: UNKNOWN

DOI: 10.17487/RFC 0343

RFC 344 Network Host Status

Authors: E. Westheimer.

Date: May 1972

Formats: txt html json

Obsoletes: RFC 0342

Obsoleted by: RFC 0353

Status: UNKNOWN

DOI: 10.17487/RFC 0344

RFC 345 Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN)

Authors: K.C. Kelley.

Date: May 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0345

RFC 346 Satellite Considerations

Authors: J. Postel.

Date: May 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0346

RFC 347 Echo process

Authors: J. Postel.

Date: May 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0347

RFC 348 Discard Process

Authors: J. Postel.

Date: May 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0348

RFC 349 Proposed Standard Socket Numbers

Authors: J. Postel.

Date: May 1972

Formats: txt html json

Obsoleted by: RFC 0433

Also: RFC 0204, RFC 0322

Status: UNKNOWN

DOI: 10.17487/RFC 0349

RFC 350 User Accounts for UCSB On-Line System

Authors: R. Stoughton.

Date: May 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0350

RFC 351 Graphics information form for the ARPANET graphics resources notebook

Authors: D. Crocker.

Date: June 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0351

RFC 352 TIP Site Information Form

Authors: D. Crocker.

Date: June 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0352

RFC 353 Network host status

Authors: E. Westheimer.

Date: June 1972

Formats: txt json html

Obsoletes: RFC 0344

Obsoleted by: RFC 0362

Status: UNKNOWN

DOI: 10.17487/RFC 0353

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 355 Response to NWG/RFC 346

Authors: J. Davidson.

Date: June 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0355

RFC 356 ARPA Network Control Center

Authors: R. Alter.

Date: June 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0356

RFC 357 Echoing strategy for satellite links

Authors: J. Davidson.

Date: June 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0357

RFC 359 Status of the Release of the New IMP System (2600)

Authors: D.C. Walden.

Date: June 1972

Formats: txt html json

Obsoletes: RFC 0343

Status: UNKNOWN

DOI: 10.17487/RFC 0359

RFC 360 Proposed Remote Job Entry Protocol

Authors: C. Holland.

Date: June 1972

Formats: txt html pdf json

Obsoleted by: RFC 0407

Status: UNKNOWN

DOI: 10.17487/RFC 0360

RFC 361 Deamon Processes on Host 106

Authors: R.D. Bressler.

Date: July 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0361

RFC 362 Network Host Status

Authors: E. Westheimer.

Date: June 1972

Formats: txt json html

Obsoletes: RFC 0353

Obsoleted by: RFC 0366

Status: UNKNOWN

DOI: 10.17487/RFC 0362

RFC 363 ARPA Network mailing lists

Authors: Network Information Center. Stanford Research Institute.

Date: August 1972

Formats: txt json html

Obsoletes: RFC 0329

Obsoleted by: RFC 0402

Status: UNKNOWN

DOI: 10.17487/RFC 0363

RFC 364 Serving remote users on the ARPANET

Authors: M.D. Abrams.

Date: July 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0364

RFC 365 Letter to All TIP Users

Authors: D.C. Walden.

Date: July 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0365

RFC 366 Network Host Status

Authors: E. Westheimer.

Date: July 1972

Formats: txt json html

Obsoletes: RFC 0362

Obsoleted by: RFC 0367

Status: UNKNOWN

DOI: 10.17487/RFC 0366

RFC 367 Network host status

Authors: E. Westheimer.

Date: July 1972

Formats: txt json html

Obsoletes: RFC 0366

Obsoleted by: RFC 0370

Status: UNKNOWN

DOI: 10.17487/RFC 0367

RFC 368 Comments on "Proposed Remote Job Entry Protocol"

Authors: R.T. Braden.

Date: July 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0368

RFC 369 Evaluation of ARPANET services January-March, 1972

Authors: J.R. Pickens.

Date: July 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0369

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 371 Demonstration at International Computer Communications Conference

Authors: R.E. Kahn.

Date: July 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0371

RFC 372 Notes on a Conversation with Bob Kahn on the ICCC

Authors: R.W. Watson.

Date: July 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0372

RFC 373 Arbitrary Character Sets

Authors: J. McCarthy.

Date: July 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0373

RFC 374 IMP System Announcement

Authors: A.M. McKenzie.

Date: July 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0374

RFC 376 Network Host Status

Authors: E. Westheimer.

Date: August 1972

Formats: txt json html

Updates: RFC 0370

Status: UNKNOWN

DOI: 10.17487/RFC 0376

RFC 377 Using TSO via ARPA Network Virtual Terminal

Authors: R.T. Braden.

Date: August 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0377

RFC 378 Traffic statistics (July 1972)

Authors: A.M. McKenzie.

Date: August 1972

Formats: txt html json

Obsoleted by: RFC 0391

Status: UNKNOWN

DOI: 10.17487/RFC 0378

RFC 379 Using TSO at CCN

Authors: R. Braden.

Date: August 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0379

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 382 Mathematical Software on the ARPA Network

Authors: L. McDaniel.

Date: August 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0382

RFC 384 Official site idents for organizations in the ARPA Network

Authors: J.B. North.

Date: August 1972

Formats: txt html json

Obsoletes: RFC 0289

Status: UNKNOWN

DOI: 10.17487/RFC 0384

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 386 Letter to TIP users-2

Authors: B. Cosell, D.C. Walden.

Date: August 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0386

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 388 NCP statistics

Authors: V. Cerf.

Date: August 1972

Formats: txt html json

Updates: RFC 0323

Status: UNKNOWN

DOI: 10.17487/RFC 0388

RFC 389 UCLA Campus Computing Network Liaison Staff for ARPA Network

Authors: B. Noble.

Date: August 1972

Formats: txt html json

Obsoleted by: RFC 0423

Status: UNKNOWN

DOI: 10.17487/RFC 0389

RFC 390 TSO Scenario

Authors: R.T. Braden.

Date: September 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0390

RFC 391 Traffic statistics (August 1972)

Authors: A.M. McKenzie.

Date: September 1972

Formats: txt html json

Obsoletes: RFC 0378

Status: UNKNOWN

DOI: 10.17487/RFC 0391

RFC 392 Measurement of host costs for transmitting network data

Authors: G. Hicks, B.D. Wessler.

Date: September 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0392

RFC 393 Comments on Telnet Protocol Changes

Authors: J.M. Winett.

Date: October 1972

Formats: txt json html

Also: RFC 0109, RFC 0139, RFC 0158, RFC 0318, RFC 0328

Status: UNKNOWN

DOI: 10.17487/RFC 0393

RFC 394 Two Proposed Changes to the IMP-Host Protocol

Authors: J.M. McQuillan.

Date: September 1972

Formats: txt html json

Updates: RFC 0381

Status: UNKNOWN

DOI: 10.17487/RFC 0394

RFC 395 Switch Settings on IMPs and TIPs

Authors: J.M. McQuillan.

Date: October 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0395

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 398 UCSB Online Graphics

Authors: J.R. Pickens, E. Faeh.

Date: September 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0398

RFC 399 SMFS Login and Logout

Authors: M. Krilanovich.

Date: September 1972

Formats: txt html json

Obsoleted by: RFC 0431

Updates: RFC 0122

Status: UNKNOWN

DOI: 10.17487/RFC 0399

RFC 400 Traffic Statistics (September 1972)

Authors: A.M. McKenzie.

Date: October 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0400

RFC 401 Conversion of NGP-0 Coordinates to Device Specific Coordinates

Authors: J. Hansen.

Date: October 1972

Formats: txt html json

Updates: RFC 0387

Status: UNKNOWN

DOI: 10.17487/RFC 0401

RFC 402 ARPA Network Mailing Lists

Authors: J.B. North.

Date: October 1972

Formats: txt json html

Obsoletes: RFC 0363

Status: UNKNOWN

DOI: 10.17487/RFC 0402

RFC 403 Desirability of a Network 1108 Service

Authors: G. Hicks.

Date: January 1973

Formats: txt json pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0403

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 405 Correction to RFC 404

Authors: A.M. McKenzie.

Date: October 1972

Formats: txt html json

Updates: RFC 0404

Status: UNKNOWN

DOI: 10.17487/RFC 0405

RFC 406 Scheduled IMP Software Releases

Authors: J.M. McQuillan.

Date: October 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0406

RFC 407 Remote Job Entry Protocol

Authors: R.D. Bressler, R. Guida, A.M. McKenzie.

Date: October 1972

Formats: txt json html

Obsoletes: RFC 0360

Status: HISTORIC

DOI: 10.17487/RFC 0407

RFC 408 NETBANK

Authors: A.D. Owen, J. Postel.

Date: October 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0408

RFC 409 Tenex interface to UCSB's Simple-Minded File System

Authors: J.E. White.

Date: December 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0409

RFC 410 Removal of the 30-Second Delay When Hosts Come Up

Authors: J.M. McQuillan.

Date: November 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0410

RFC 411 New MULTICS Network Software Features

Authors: M.A. Padlipsky.

Date: November 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0411

RFC 412 User FTP Documentation

Authors: G. Hicks.

Date: November 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0412

RFC 413 Traffic statistics (October 1972)

Authors: A.M. McKenzie.

Date: November 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0413

RFC 414 File Transfer Protocol (FTP) status and further comments

Authors: A.K. Bhushan.

Date: December 1972

Formats: txt html json

Updates: RFC 0385

Status: UNKNOWN

DOI: 10.17487/RFC 0414

RFC 415 Tenex bandwidth

Authors: H. Murray.

Date: November 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0415

RFC 416 ARC System Will Be Unavailable for Use During Thanksgiving Week

Authors: J.C. Norton.

Date: November 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0416

RFC 417 Link usage violation

Authors: J. Postel, C. Kline.

Date: December 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0417

RFC 418 Server File Transfer Under TSS/360 At NASA-Ames Research Center

Authors: W. Hathaway.

Date: November 1972

Formats: json pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0418

RFC 419 To: Network liaisons and station agents

Authors: A. Vezza.

Date: December 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0419

RFC 420 CCA ICCC weather demo

Authors: H. Murray.

Date: January 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0420

RFC 421 Software Consulting Service for Network Users

Authors: A.M. McKenzie.

Date: November 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0421

RFC 422 Traffic statistics (November 1972)

Authors: A.M. McKenzie.

Date: December 1972

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0422

RFC 423 UCLA Campus Computing Network Liaison Staff for ARPANET

Authors: B. Noble.

Date: December 1972

Formats: txt json html

Obsoletes: RFC 0389

Status: UNKNOWN

DOI: 10.17487/RFC 0423

RFC 425 "But my NCP costs $500 a day"

Authors: R.D. Bressler.

Date: December 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0425

RFC 426 Reconnection Protocol

Authors: R. Thomas.

Date: January 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0426

RFC 429 Character Generator Process

Authors: J. Postel.

Date: December 1972

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0429

RFC 430 Comments on File Transfer Protocol

Authors: R.T. Braden.

Date: February 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0430

RFC 431 Update on SMFS Login and Logout

Authors: M. Krilanovich.

Date: December 1972

Formats: txt html json

Obsoletes: RFC 0399

Updates: RFC 0122

Status: UNKNOWN

DOI: 10.17487/RFC 0431

RFC 432 Network logical map

Authors: N. Neigus.

Date: December 1972

Formats: txt json ps pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0432

RFC 433 Socket number list

Authors: J. Postel.

Date: December 1972

Formats: txt json html

Obsoletes: RFC 0349

Obsoleted by: RFC 0503

Status: UNKNOWN

DOI: 10.17487/RFC 0433

RFC 434 IMP/TIP memory retrofit schedule

Authors: A.M. McKenzie.

Date: January 1973

Formats: txt html json

Obsoleted by: RFC 0447

Status: UNKNOWN

DOI: 10.17487/RFC 0434

RFC 435 Telnet issues

Authors: B. Cosell, D.C. Walden.

Date: January 1973

Formats: txt html json

Updates: RFC 0318

Status: UNKNOWN

DOI: 10.17487/RFC 0435

RFC 436 Announcement of RJS at UCSB

Authors: M. Krilanovich.

Date: January 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0436

RFC 437 Data Reconfiguration Service at UCSB

Authors: E. Faeh.

Date: June 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0437

RFC 438 FTP server-server interaction

Authors: R. Thomas, R. Clements.

Date: January 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0438

RFC 439 PARRY encounters the DOCTOR

Authors: V. Cerf.

Date: January 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0439

RFC 440 Scheduled network software maintenance

Authors: D.C. Walden.

Date: January 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0440

RFC 441 Inter-Entity Communication - an experiment

Authors: R.D. Bressler, R. Thomas.

Date: January 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0441

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 443 Traffic statistics (December 1972)

Authors: A.M. McKenzie.

Date: January 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0443

RFC 445 IMP/TIP preventive maintenance schedule

Authors: A.M. McKenzie.

Date: January 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0445

RFC 446 Proposal to consider a network program resource notebook

Authors: L.P. Deutsch.

Date: January 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0446

RFC 447 IMP/TIP memory retrofit schedule

Authors: A.M. McKenzie.

Date: January 1973

Formats: txt html json

Obsoletes: RFC 0434

Obsoleted by: RFC 0476

Status: UNKNOWN

DOI: 10.17487/RFC 0447

RFC 448 Print files in FTP

Authors: R.T. Braden.

Date: February 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0448

RFC 449 Current flow-control scheme for IMPSYS

Authors: D.C. Walden.

Date: January 1973

Formats: txt json html

Updates: RFC 0442

Status: UNKNOWN

DOI: 10.17487/RFC 0449

RFC 450 MULTICS sampling timeout change

Authors: M.A. Padlipsky.

Date: February 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0450

RFC 451 Tentative proposal for a Unified User Level Protocol

Authors: M.A. Padlipsky.

Date: February 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0451

RFC 452 TELNET Command at Host LL

Authors: J. Winett.

Date: February 1973

Formats: txt pdf html json

Status: UNKNOWN

DOI: 10.17487/RFC 0452

RFC 453 Meeting announcement to discuss a network mail system

Authors: M.D. Kudlick.

Date: February 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0453

RFC 454 File Transfer Protocol - meeting announcement and a new proposed document

Authors: A.M. McKenzie.

Date: February 1973

Formats: txt json html

Updates: RFC 0354

Status: UNKNOWN

DOI: 10.17487/RFC 0454

RFC 455 Traffic statistics (January 1973)

Authors: A.M. McKenzie.

Date: February 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0455

RFC 456 Memorandum: Date change of mail meeting

Authors: M.D. Kudlick.

Date: February 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0456

RFC 457 TIPUG

Authors: D.C. Walden.

Date: February 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0457

RFC 458 Mail retrieval via FTP

Authors: R.D. Bressler, R. Thomas.

Date: February 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0458

RFC 459 Network questionnaires

Authors: W. Kantrowitz.

Date: February 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0459

RFC 460 NCP survey

Authors: C. Kline.

Date: February 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0460

RFC 461 Telnet Protocol meeting announcement

Authors: A.M. McKenzie.

Date: February 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0461

RFC 462 Responding to user needs

Authors: J. Iseli, D. Crocker.

Date: February 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0462

RFC 463 FTP comments and response to RFC 430

Authors: A.K. Bhushan.

Date: February 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0463

RFC 464 Resource notebook framework

Authors: M.D. Kudlick.

Date: February 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0464

RFC 466 Telnet logger/server for host LL-67

Authors: J.M. Winett.

Date: February 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0466

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 468 FTP data compression

Authors: R.T. Braden.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0468

RFC 469 Network mail meeting summary

Authors: M.D. Kudlick.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0469

RFC 470 Change in socket for TIP news facility

Authors: R. Thomas.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0470

RFC 471 Workshop on multi-site executive programs

Authors: R. Thomas.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0471

RFC 472 Illinois' reply to Maxwell's request for graphics information (NIC 14925)

Authors: S. Bunch.

Date: March 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0472

RFC 473 MIX and MIXAL?

Authors: D.C. Walden.

Date: February 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0473

RFC 474 Announcement of NGWG meeting: Call for papers

Authors: S. Bunch.

Date: March 1973

Formats: txt json html

Updates: RFC 0396

Status: UNKNOWN

DOI: 10.17487/RFC 0474

RFC 475 FTP and Network Mail System

Authors: A.K. Bhushan.

Date: March 1973

Formats: txt json html pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0475

RFC 476 IMP/TIP memory retrofit schedule (rev 2)

Authors: A.M. McKenzie.

Date: March 1973

Formats: txt html json

Obsoletes: RFC 0447

Status: UNKNOWN

DOI: 10.17487/RFC 0476

RFC 477 Remote Job Service at UCSB

Authors: M. Krilanovich.

Date: May 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0477

RFC 478 FTP server-server interaction - II

Authors: R.D. Bressler, R. Thomas.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0478

RFC 479 Use of FTP by the NIC Journal

Authors: J.E. White.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0479

RFC 480 Host-dependent FTP parameters

Authors: J.E. White.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0480

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 483 Cancellation of the resource notebook framework meeting

Authors: M.D. Kudlick.

Date: March 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0483

RFC 485 MIX and MIXAL at UCSB

Authors: J.R. Pickens.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0485

RFC 486 Data transfer revisited

Authors: R.D. Bressler.

Date: March 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0486

RFC 487 Free file transfer

Authors: R.D. Bressler.

Date: April 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0487

RFC 488 NLS classes at network sites

Authors: M.F. Auerbach.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0488

RFC 489 Comment on resynchronization of connection status proposal

Authors: J. Postel.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0489

RFC 490 Surrogate RJS for UCLA-CCN

Authors: J.R. Pickens.

Date: March 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0490

RFC 491 What is "Free"?

Authors: M.A. Padlipsky.

Date: April 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0491

RFC 492 Response to RFC 467

Authors: E. Meyer.

Date: April 1973

Formats: txt html json

Updates: RFC 0467

Status: UNKNOWN

DOI: 10.17487/RFC 0492

RFC 493 GRAPHICS PROTOCOL

Authors: J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. Liddle, E. Meyer.

Date: April 1973

Formats: txt html pdf json

Obsoletes: RFC 0292

Status: UNKNOWN

DOI: 10.17487/RFC 0493

RFC 494 Availability of MIX and MIXAL in the Network

Authors: D.C. Walden.

Date: April 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0494

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 496 TNLS quick reference card is available

Authors: M.F. Auerbach.

Date: April 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0496

RFC 497 Traffic Statistics (March 1973)

Authors: A.M. McKenzie.

Date: April 1973

Formats: txt html pdf json

Updates: RFC 0482

Status: UNKNOWN

DOI: 10.17487/RFC 0497

RFC 498 On mail service to CCN

Authors: R.T. Braden.

Date: April 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0498

RFC 499 Harvard's network RJE

Authors: B.R. Reussow.

Date: April 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0499

RFC 500 Integration of data management systems on a computer network

Authors: A. Shoshani, I. Spiegler.

Date: April 1973

Formats: json pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0500

RFC 501 Un-muddling "free file transfer"

Authors: K.T. Pogran.

Date: May 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0501

RFC 503 Socket number list

Authors: N. Neigus, J. Postel.

Date: April 1973

Formats: txt html json

Obsoletes: RFC 0433

Obsoleted by: RFC 0739

Status: UNKNOWN

DOI: 10.17487/RFC 0503

RFC 504 Distributed resources workshop announcement

Authors: R. Thomas.

Date: April 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0504

RFC 505 Two solutions to a file transfer access problem

Authors: M.A. Padlipsky.

Date: June 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0505

RFC 506 FTP command naming problem

Authors: M.A. Padlipsky.

Date: June 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0506

RFC 508 Real-time data transmission on the ARPANET

Authors: L. Pfeifer, J. McAfee.

Date: May 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0508

RFC 509 Traffic statistics (April 1973)

Authors: A.M. McKenzie.

Date: April 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0509

RFC 510 Request for network mailbox addresses

Authors: J.E. White.

Date: May 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0510

RFC 511 Enterprise phone service to NIC from ARPANET sites

Authors: J.B. North.

Date: May 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0511

RFC 512 More on lost message detection

Authors: W. Hathaway.

Date: May 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0512

RFC 513 Comments on the new Telnet specifications

Authors: W. Hathaway.

Date: May 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0513

RFC 514 Network make-work

Authors: W. Kantrowitz.

Date: June 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0514

RFC 515 Specifications for Datalanguage, Version 0/9

Authors: R. Winter.

Date: June 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0515

RFC 516 Lost message detection

Authors: J. Postel.

Date: May 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0516

RFC 518 ARPANET accounts

Authors: N. Vaughan, E.J. Feinler.

Date: June 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0518

RFC 519 Resource Evaluation

Authors: J.R. Pickens.

Date: June 1973

Formats: txt json pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0519

In the spirit of RFC # 369, Evaluation of ARPANET resources, a new test group was organized at UCSB to take a detailed look at specific network resources and develop initial site dependent and function dependent MINIMAN's (Concise User Manuals). As the group was again composed of novices, initial effort revolved about basic procedural indoctrination. In the period between January and March 1973 a number of resources were investigated with varying degrees of success, as to availability, proper usage, sample problem solutions, and access to help and documentation. Included in this paper are a summary of the projects undertaken, initial suggestions at MINIMAN composition, and suggestions for future test groups. As these groups are attempting to perform a useful function for the ARPANET community, comments and suggestions are requested. Copies of the reports described herein are available on request from the ComputerSystems Laboratory at UCSB.

RFC 520 Memo to FTP group: Proposal for File Access Protocol

Authors: J.D. Day.

Date: June 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0520

RFC 521 Restricted use of IMP DDT

Authors: A.M. McKenzie.

Date: May 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0521

RFC 522 Traffic Statistics (May 1973)

Authors: A.M. McKenzie.

Date: June 1973

Formats: txt html pdf json

Updates: RFC 0509

Status: UNKNOWN

DOI: 10.17487/RFC 0522

RFC 523 SURVEY is in operation again

Authors: A.K. Bhushan.

Date: June 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0523

RFC 524 Proposed Mail Protocol

Authors: J.E. White.

Date: June 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0524

RFC 525 MIT-MATHLAB meets UCSB-OLS -an example of resource sharing

Authors: W. Parrish, J.R. Pickens.

Date: June 1973

Formats: txt json pdf html ps

Status: UNKNOWN

DOI: 10.17487/RFC 0525

RFC 526 Technical meeting: Digital image processing software systems

Authors: W.K. Pratt.

Date: June 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0526

RFC 527 ARPAWOCKY

Authors: R. Merryman.

Date: May 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0527

RFC 528 Software checksumming in the IMP and network reliability

Authors: J.M. McQuillan.

Date: June 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0528

RFC 529 Note on protocol synch sequences

Authors: A.M. McKenzie, R. Thomas, R.S. Tomlinson, K.T. Pogran.

Date: June 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0529

RFC 530 Report on the Survey Project

Authors: A.K. Bhushan.

Date: June 1973

Formats: json pdf

Updates: RFC 0308, RFC 0523

Status: UNKNOWN

DOI: 10.17487/RFC 0530

RFC 531 Feast or famine? A response to two recent RFC's about network information

Authors: M.A. Padlipsky.

Date: June 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0531

RFC 532 UCSD-CC Server-FTP facility

Authors: R.G. Merryman.

Date: July 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0532

RFC 533 Message-ID numbers

Authors: D.C. Walden.

Date: July 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0533

RFC 534 Lost message detection

Authors: D.C. Walden.

Date: July 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0534

RFC 535 Comments on File Access Protocol

Authors: R. Thomas.

Date: July 1973

Formats: txt json html pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0535

RFC 537 Announcement of NGG meeting July 16-17

Authors: S. Bunch.

Date: June 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0537

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 539 Thoughts on the mail protocol proposed in RFC 524

Authors: D. Crocker, J. Postel.

Date: July 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0539

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 543 Network journal submission and delivery

Authors: N.D. Meyer.

Date: July 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0543

RFC 544 Locating on-line documentation at SRI-ARC

Authors: N.D. Meyer, K. Kelley.

Date: July 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0544

RFC 545 Of what quality be the UCSB resources evaluators?

Authors: J.R. Pickens.

Date: July 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0545

RFC 546 Tenex load averages for July 1973

Authors: R. Thomas.

Date: August 1973

Formats: txt json ps pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0546

RFC 547 Change to the Very Distant Host specification

Authors: D.C. Walden.

Date: August 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0547

RFC 548 Hosts using the IMP Going Down message

Authors: D.C. Walden.

Date: August 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0548

RFC 549 Minutes of Network Graphics Group meeting, 15-17 July 1973

Authors: J.C. Michener.

Date: July 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0549

RFC 550 NIC NCP experiment

Authors: L.P. Deutsch.

Date: August 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0550

RFC 551 NYU, ANL, and LBL Joining the Net

Authors: Y. Feinroth, R. Fink.

Date: August 1973

Formats: txt html json pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0551

RFC 552 Single access to standard protocols

Authors: A.D. Owen.

Date: July 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0552

RFC 553 Draft design for a text/graphics protocol

Authors: C.H. Irby, K. Victor.

Date: July 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0553

RFC 555 Responses to critiques of the proposed mail protocol

Authors: J.E. White.

Date: July 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0555

RFC 556 Traffic Statistics (July 1973)

Authors: A.M. McKenzie.

Date: August 1973

Formats: txt json pdf html

Updates: RFC 0538

Status: UNKNOWN

DOI: 10.17487/RFC 0556

RFC 557 REVELATIONS IN NETWORK HOST MEASUREMENTS

Authors: B.D. Wessler.

Date: August 1973

Formats: txt json pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0557

RFC 559 Comments on The New Telnet Protocol and its Implementation

Authors: A.K. Bushan.

Date: August 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0559

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 562 Modifications to the TELNET Specification

Authors: A.M. McKenzie.

Date: August 1973

Formats: txt json html pdf

Updates: RFC 0495

Status: UNKNOWN

DOI: 10.17487/RFC 0562

RFC 563 Comments on the RCTE Telnet option

Authors: J. Davidson.

Date: August 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0563

RFC 565 Storing network survey data at the datacomputer

Authors: D. Cantor.

Date: August 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0565

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 568 Response to RFC 567 - cross country network bandwidth

Authors: J.M. McQuillan.

Date: September 1973

Formats: txt html json

Updates: RFC 0567

Status: UNKNOWN

DOI: 10.17487/RFC 0568

RFC 569 NETED: A Common Editor for the ARPA Network

Authors: M.A. Padlipsky.

Date: October 1973

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0569

RFC 570 Experimental input mapping between NVT ASCII and UCSB On Line System

Authors: J.R. Pickens.

Date: October 1973

Formats: txt ps pdf html json

Status: UNKNOWN

DOI: 10.17487/RFC 0570

RFC 571 TENEX FTP PROBLEM

Authors: R. Braden.

Date: November 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0571

RFC 573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS

Authors: A. Bhushan.

Date: September 1973

Formats: txt json pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0573

RFC 574 Announcement of a Mail Facility at UCSB

Authors: M. Krilanovich.

Date: September 1973

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0574

RFC 576 Proposal for modifying linking

Authors: K. Victor.

Date: September 1973

Formats: txt pdf json html

Status: UNKNOWN

DOI: 10.17487/RFC 0576

RFC 577 Mail priority

Authors: D. Crocker.

Date: October 1973

Formats: txt json pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0577

RFC 578 Using MIT-Mathlab MACSYMA from MIT-DMS Muddle

Authors: A.K. Bhushan, N.D. Ryan.

Date: October 1973

Formats: txt pdf html json

Status: UNKNOWN

DOI: 10.17487/RFC 0578

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 581 Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option

Authors: D. Crocker, J. Postel.

Date: November 1973

Formats: txt html pdf json

Updates: RFC 0560

Status: UNKNOWN

DOI: 10.17487/RFC 0581

RFC 582 Comments on RFC 580: Machine readable protocols

Authors: R. Clements.

Date: November 1973

Formats: txt json html

Updates: RFC 0580

Status: UNKNOWN

DOI: 10.17487/RFC 0582

RFC 584 Charter for ARPANET Users Interest Working Group

Authors: J. Iseli, D. Crocker, N. Neigus.

Date: November 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0584

RFC 585 ARPANET users interest working group meeting

Authors: D. Crocker, N. Neigus, E.J. Feinler, J. Iseli.

Date: November 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0585

RFC 586 Traffic statistics (October 1973)

Authors: A.M. McKenzie.

Date: November 1973

Formats: txt json pdf html

Updates: RFC 0579

Status: UNKNOWN

DOI: 10.17487/RFC 0586

RFC 587 Announcing New Telnet Options

Authors: J. Postel.

Date: November 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0587

RFC 588 London Node Is Now Up

Authors: A. Stokes.

Date: October 1973

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0588

RFC 589 CCN NETRJS server messages to remote user

Authors: R.T. Braden.

Date: November 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0589

RFC 590 MULTICS address change

Authors: M.A. Padlipsky.

Date: November 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0590

RFC 591 Addition to the Very Distant Host specifications

Authors: D.C. Walden.

Date: November 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0591

RFC 592 Some thoughts on system design to facilitate resource sharing

Authors: R.W. Watson.

Date: November 1973

Formats: txt pdf json html

Status: UNKNOWN

DOI: 10.17487/RFC 0592

RFC 593 Telnet and FTP implementation schedule change

Authors: A.M. McKenzie, J. Postel.

Date: November 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0593

RFC 594 Speedup of Host-IMP interface

Authors: J.D. Burchfiel.

Date: December 1973

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0594

RFC 595 Second thoughts in defense of the Telnet Go-Ahead

Authors: W. Hathaway.

Date: December 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0595

RFC 596 Second thoughts on Telnet Go-Ahead

Authors: E.A. Taft.

Date: December 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0596

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 598 RFC index - December 5, 1973

Authors: Network Information Center. Stanford Research Institute.

Date: December 1973

Formats: json pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0598

RFC 599 Update on NETRJS

Authors: R.T. Braden.

Date: December 1973

Formats: txt html json

Obsoletes: RFC 0189

Obsoleted by: RFC 0740

Status: UNKNOWN

DOI: 10.17487/RFC 0599

RFC 600 Interfacing an Illinois plasma terminal to the ARPANET

Authors: A. Berggreen.

Date: November 1973

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0600

RFC 601 Traffic statistics (November 1973)

Authors: A.M. McKenzie.

Date: December 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0601

RFC 602 "The stockings were hung by the chimney with care"

Authors: R.M. Metcalfe.

Date: December 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0602

Susceptibility of ARPANET to security violations.

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 604 Assigned link numbers

Authors: J. Postel.

Date: December 1973

Formats: txt html json

Obsoletes: RFC 0317

Obsoleted by: RFC 0739

Status: UNKNOWN

DOI: 10.17487/RFC 0604

Modifies official host-host protocol. Replaces RFC 377.

RFC 606 Host names on-line

Authors: L.P. Deutsch.

Date: December 1973

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0606

Resolving differences in hostname-address mappings; see also RFCs 627, 625, 623 and 608.

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 608 Host names on-line

Authors: M.D. Kudlick.

Date: January 1974

Formats: txt html json

Obsoleted by: RFC 0810

Status: UNKNOWN

DOI: 10.17487/RFC 0608

Response to RFC 606; see also RFCs 627, 625 and 623.

RFC 609 Statement of upcoming move of NIC/NLS service

Authors: B. Ferguson.

Date: January 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0609

See also RFCs 621 and 620.

RFC 610 Further datalanguage design concepts

Authors: R. Winter, J. Hill, W. Greiff.

Date: December 1973

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0610

Preliminary results of the language design; a model for data languagea semantics; future considerations.

RFC 611 Two changes to the IMP/Host Protocol to improve user/network communications

Authors: D.C. Walden.

Date: February 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0611

Expansion of Host-Going-Down and addition of Dead-Host-Status Message.

RFC 612 Traffic statistics (December 1973)

Authors: A.M. McKenzie.

Date: January 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0612

RFC 613 Network connectivity: A response to RFC 603

Authors: A.M. McKenzie.

Date: January 1974

Formats: txt json html

Updates: RFC 0603

Status: UNKNOWN

DOI: 10.17487/RFC 0613

RFC 614 Response to RFC 607: "Comments on the File Transfer Protocol"

Authors: K.T. Pogran, N. Neigus.

Date: January 1974

Formats: txt html json

Updates: RFC 0542, RFC 0607

Status: UNKNOWN

DOI: 10.17487/RFC 0614

See also RFCs 624, 542 and 640.

RFC 615 Proposed Network Standard Data Pathname syntax

Authors: D. Crocker.

Date: March 1974

Formats: txt html json

Obsoleted by: RFC 0645

Status: UNKNOWN

DOI: 10.17487/RFC 0615

RFC 616 LATEST NETWORK MAPS

Authors: D. Walden.

Date: February 1973

Formats: txt json html pdf

Status: UNKNOWN

DOI: 10.17487/RFC 0616

RFC 617 Note on socket number assignment

Authors: E.A. Taft.

Date: February 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0617

Danger of imposing more fixed socket number requirements; see also RFCs 542, 503 and 451.

RFC 618 Few observations on NCP statistics

Authors: E.A. Taft.

Date: February 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0618

Distribution of NCP and IMP message types by actual measurement.

RFC 619 Mean round-trip times in the ARPANET

Authors: W. Naylor, H. Opderbeck.

Date: March 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0619

Actual measurements of round-trip times.

RFC 620 Request for monitor host table updates

Authors: B. Ferguson.

Date: March 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0620

In conjunction with moving NIC users to OFFICE-1; see also RFCs 621 and 609.

RFC 621 NIC user directories at SRI ARC

Authors: M.D. Kudlick.

Date: March 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0621

See also RFCs 620 and 609.

RFC 622 Scheduling IMP/TIP down time

Authors: A.M. McKenzie.

Date: March 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0622

Modification of previous policy.

RFC 623 Comments on on-line host name service

Authors: M. Krilanovich.

Date: February 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0623

See also RFCs 627, 625, 608 and 606.

RFC 624 Comments on the File Transfer Protocol

Authors: M. Krilanovich, G. Gregg, W. Hathaway, J.E. White.

Date: February 1974

Formats: txt html json

Obsoletes: RFC 0607

Status: UNKNOWN

DOI: 10.17487/RFC 0624

Design changes and slight modifications. Replaces RFC 607; see also RFCs 614, 542 and 640.

RFC 625 On-line hostnames service

Authors: M.D. Kudlick, E.J. Feinler.

Date: March 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0625

See also RFCs 606, 608, 623 and 627.

RFC 626 On a possible lockup condition in IMP subnet due to message sequencing

Authors: L. Kleinrock, H. Opderbeck.

Date: March 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0626

RFC 627 ASCII text file of hostnames

Authors: M.D. Kudlick, E.J. Feinler.

Date: March 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0627

See also RFCs 606, 608, 623 and 625.

RFC 628 Status of RFC numbers and a note on pre-assigned journal numbers

Authors: M.L. Keeney.

Date: March 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0628

RFC 629 Scenario for using the Network Journal

Authors: J.B. North.

Date: March 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0629

RFC 630 FTP error code usage for more reliable mail service

Authors: J. Sussman.

Date: April 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0630

Describes FTP reply-code usage in TENEX mail processing.

RFC 631 International meeting on minicomputers and data communication: Call for papers

Authors: A. Danthine.

Date: April 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0631

RFC 632 Throughput degradations for single packet messages

Authors: H. Opderbeck.

Date: May 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0632

RFC 633 IMP/TIP preventive maintenance schedule

Authors: A.M. McKenzie.

Date: March 1974

Formats: txt json html

Obsoleted by: RFC 0638

Status: UNKNOWN

DOI: 10.17487/RFC 0633

An old version; see RFC 638.

RFC 634 Change in network address for Haskins Lab

Authors: A.M. McKenzie.

Date: April 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0634

RFC 635 Assessment of ARPANET protocols

Authors: V. Cerf.

Date: April 1974

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0635

RFC 636 TIP/Tenex reliability improvements

Authors: J.D. Burchfiel, B. Cosell, R.S. Tomlinson, D.C. Walden.

Date: June 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0636

Obtaining/maintaining connections; recovery from lost connections; connection-state changes.

RFC 637 Change of network address for SU-DSL

Authors: A.M. McKenzie.

Date: April 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0637

RFC 638 IMP/TIP preventive maintenance schedule

Authors: A.M. McKenzie.

Date: April 1974

Formats: txt html json

Obsoletes: RFC 0633

Status: UNKNOWN

DOI: 10.17487/RFC 0638

Corrects RFC 633.

RFC 640 Revised FTP reply codes

Authors: J. Postel.

Date: June 1974

Formats: txt json html

Updates: RFC 0542

Status: UNKNOWN

DOI: 10.17487/RFC 0640

Updates RFC 542.

RFC 642 Ready line philosophy and implementation

Authors: J.D. Burchfiel.

Date: July 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0642

RFC 643 Network Debugging Protocol

Authors: E. Mader.

Date: July 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0643

To be used in an implementation of a PDP-11 network bootstrap device and a cross-network debugger.

RFC 644 On the problem of signature authentication for network mail

Authors: R. Thomas.

Date: July 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0644

RFC 645 Network Standard Data Specification syntax

Authors: D. Crocker.

Date: June 1974

Formats: txt pdf json html

Obsoletes: RFC 0615

Status: UNKNOWN

DOI: 10.17487/RFC 0645

RFC 647 Proposed protocol for connecting host computers to ARPA-like networks via front end processors

Authors: M.A. Padlipsky.

Date: November 1974

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0647

RFC 651 Revised Telnet status option

Authors: D. Crocker.

Date: October 1974

Formats: txt json html

Obsoleted by: RFC 0859

Status: UNKNOWN

DOI: 10.17487/RFC 0651

RFC 652 Telnet output carriage-return disposition option

Authors: D. Crocker.

Date: October 1974

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0652

RFC 653 Telnet output horizontal tabstops option

Authors: D. Crocker.

Date: October 1974

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0653

RFC 654 Telnet output horizontal tab disposition option

Authors: D. Crocker.

Date: October 1974

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 0654

RFC 655 Telnet output formfeed disposition option

Authors: D. Crocker.

Date: October 1974

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 0655

RFC 656 Telnet output vertical tabstops option

Authors: D. Crocker.

Date: October 1974

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0656

RFC 657 Telnet output vertical tab disposition option

Authors: D. Crocker.

Date: October 1974

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0657

RFC 658 Telnet output linefeed disposition

Authors: D. Crocker.

Date: October 1974

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 0658

RFC 659 Announcing additional Telnet options

Authors: J. Postel.

Date: October 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0659

Options defined in RFCs 651-658.

RFC 660 Some changes to the IMP and the IMP/Host interface

Authors: D.C. Walden.

Date: October 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0660

Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.

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 662 Performance improvement in ARPANET file transfers from Multics

Authors: R. Kanodia.

Date: November 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0662

Experimenting with host output buffers to improve throughput.

RFC 663 Lost message detection and recovery protocol

Authors: R. Kanodia.

Date: November 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0663

Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.

RFC 666 Specification of the Unified User-Level Protocol

Authors: M.A. Padlipsky.

Date: November 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0666

RFC 667 Host Ports

Authors: S.G. Chipman.

Date: December 1974

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0667

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 671 Note on Reconnection Protocol

Authors: R. Schantz.

Date: December 1974

Formats: txt json pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 0671

RFC 672 Multi-site data collection facility

Authors: R. Schantz.

Date: December 1974

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0672

Applicability of TIP/TENEX protocols beyond TIP accounting.

RFC 674 Procedure call documents: Version 2

Authors: J. Postel, J.E. White.

Date: December 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0674

Host level protocol used in the NSW--a slightly constrained version of ARPANET Host-to-Host protocol, affecting allocation, RFNM wait, and retransmission; see also RFC 684.

RFC 675 Specification of Internet Transmission Control Program

Authors: V. Cerf, Y. Dalal, C. Sunshine.

Date: December 1974

Formats: txt json html

Obsoleted by: RFC 7805

Status: HISTORIC

DOI: 10.17487/RFC 0675

The first detailed specification of TCP; see RFC 793.

RFC 677 Maintenance of duplicate databases

Authors: P.R. Johnson, R. Thomas.

Date: January 1975

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0677

RFC 678 Standard file formats

Authors: J. Postel.

Date: December 1974

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0678

For transmission of documents across different environments.

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 680 Message Transmission Protocol

Authors: T.H. Myer, D.A. Henderson.

Date: April 1975

Formats: txt json html

Updates: RFC 0561

Status: UNKNOWN

DOI: 10.17487/RFC 0680

RFC 681 Network UNIX

Authors: S. Holmgren.

Date: March 1975

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0681

Capabilities as an ARPANET Mini-Host: standard I/O, Telnet, NCP, Hardware/Software requirements, reliability, availability.

RFC 683 FTPSRV - Tenex extension for paged files

Authors: R. Clements.

Date: April 1975

Formats: txt html json

Updates: RFC 0354

Status: UNKNOWN

DOI: 10.17487/RFC 0683

Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability.

RFC 684 Commentary on procedure calling as a network protocol

Authors: R. Schantz.

Date: April 1975

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0684

Issues in designing distributed computing systems. Shortcomings of RFC 674; see also RFCs 542 and 354.

RFC 685 Response time in cross network debugging

Authors: M. Beeler.

Date: April 1975

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0685

The contribution of ARPANET communication to response time.

RFC 686 Leaving well enough alone

Authors: B. Harvey.

Date: May 1975

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0686

Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.

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 688 Tentative schedule for the new Telnet implementation for the TIP

Authors: D.C. Walden.

Date: June 1975

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0688

RFC 689 Tenex NCP finite state machine for connections

Authors: R. Clements.

Date: May 1975

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0689

Describes the internal states of an NCP connection in the TENEX implementation.

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 691 One more try on the FTP

Authors: B. Harvey.

Date: June 1975

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0691

Slight revision of RFC 686, on the subject of print files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354.

RFC 692 Comments on IMP/Host Protocol changes (RFCs 687 and 690)

Authors: S.M. Wolfe.

Date: June 1975

Formats: txt html json

Updates: RFC 0690

Status: UNKNOWN

DOI: 10.17487/RFC 0692

A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687.

RFC 694 Protocol information

Authors: J. Postel.

Date: June 1975

Formats: txt json pdf html

Updates: RFC 0661

Status: UNKNOWN

DOI: 10.17487/RFC 0694

RFC 695 Official change in Host-Host Protocol

Authors: M. Krilanovich.

Date: July 1975

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0695

Corrects ambiguity concerning the ERR command; changes NIC 8246 and NIC 7104.

RFC 696 Comments on the IMP/Host and Host/IMP Protocol changes

Authors: V.G. Cerf.

Date: July 1975

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0696

RFC 697 CWD command of FTP

Authors: J. Lieb.

Date: July 1975

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0697

Discusses FTP login access to "files only" directories.

RFC 698 Telnet extended ASCII option

Authors: T. Mock.

Date: July 1975

Formats: txt json html

Obsoleted by: RFC 5198

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0698

Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.

RFC 699 Request For Comments summary notes: 600-699

Authors: J. Postel, J. Vernon.

Date: November 1982

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 0699

RFC 700 Protocol experiment

Authors: E. Mader, W.W. Plummer, R.S. Tomlinson.

Date: August 1974

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 0700

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 703 July, 1975, survey of New-Protocol Telnet Servers

Authors: D.W. Dodds.

Date: July 1975

Formats: txt html json

Updates: RFC 0679

Status: UNKNOWN

DOI: 10.17487/RFC 0703

RFC 704 IMP/Host and Host/IMP Protocol change

Authors: P.J. Santos.

Date: September 1975

Formats: txt json html

Obsoletes: RFC 0687

Status: UNKNOWN

DOI: 10.17487/RFC 0704

RFC 705 Front-end Protocol B6700 version

Authors: R.F. Bryan.

Date: November 1975

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0705

RFC 706 On the junk mail problem

Authors: J. Postel.

Date: November 1975

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0706

RFC 707 High-level framework for network-based resource sharing

Authors: J.E. White.

Date: December 1975

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0707

RFC 708 Elements of a Distributed Programming System

Authors: J.E. White.

Date: January 1976

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0708

RFC 712 Distributed Capability Computing System (DCCS)

Authors: J.E. Donnelley.

Date: February 1976

Formats: txt html pdf json

Status: UNKNOWN

DOI: 10.17487/RFC 0712

RFC 713 MSDTP-Message Services Data Transmission Protocol

Authors: J. Haverty.

Date: April 1976

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0713

RFC 714 Host-Host Protocol for an ARPANET-Type Network

Authors: A.M. McKenzie.

Date: April 1976

Formats: txt pdf json html

Status: UNKNOWN

DOI: 10.17487/RFC 0714

RFC 716 Interim Revision to Appendix F of BBN 1822

Authors: D.C. Walden, J. Levin.

Date: May 1976

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0716

RFC 717 Assigned Network Numbers

Authors: J. Postel.

Date: July 1976

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0717

RFC 718 Comments on RCTE from the Tenex Implementation Experience

Authors: J. Postel.

Date: June 1976

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0718

RFC 719 Discussion on RCTE

Authors: J. Postel.

Date: July 1976

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0719

RFC 720 Address Specification Syntax for Network Mail

Authors: D. Crocker.

Date: August 1976

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0720

RFC 721 Out-of-Band Control Signals in a Host-to-Host Protocol

Authors: L.L. Garlick.

Date: September 1976

Formats: txt json html

Obsoleted by: RFC 7805

Status: HISTORIC

DOI: 10.17487/RFC 0721

RFC 722 Thoughts on Interactions in Distributed Services

Authors: J. Haverty.

Date: September 1976

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0722

RFC 724 Proposed official standard for the format of ARPA Network messages

Authors: D. Crocker, K.T. Pogran, J. Vittal, D.A. Henderson.

Date: May 1977

Formats: txt json html

Obsoleted by: RFC 0733

Status: UNKNOWN

DOI: 10.17487/RFC 0724

RFC 725 RJE protocol for a resource sharing network

Authors: J.D. Day, G.R. Grossman.

Date: March 1977

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0725

RFC 726 Remote Controlled Transmission and Echoing Telnet option

Authors: J. Postel, D. Crocker.

Date: March 1977

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0726

RFC 727 Telnet logout option

Authors: M.R. Crispin.

Date: April 1977

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0727

RFC 728 Minor pitfall in the Telnet Protocol

Authors: J.D. Day.

Date: April 1977

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0728

RFC 729 Telnet byte macro option

Authors: D. Crocker.

Date: May 1977

Formats: txt json html

Obsoleted by: RFC 0735

Status: UNKNOWN

DOI: 10.17487/RFC 0729

RFC 730 Extensible field addressing

Authors: J. Postel.

Date: May 1977

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0730

RFC 731 Telnet Data Entry Terminal option

Authors: J.D. Day.

Date: June 1977

Formats: txt json html

Obsoleted by: RFC 0732

Status: UNKNOWN

DOI: 10.17487/RFC 0731

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 733 Standard for the format of ARPA network text messages

Authors: D. Crocker, J. Vittal, K.T. Pogran, D.A. Henderson.

Date: November 1977

Formats: txt html json

Obsoletes: RFC 0724

Obsoleted by: RFC 0822

Status: UNKNOWN

DOI: 10.17487/RFC 0733

RFC 734 SUPDUP Protocol

Authors: M.R. Crispin.

Date: October 1977

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 0734

RFC 735 Revised Telnet byte macro option

Authors: D. Crocker, R.H. Gumpertz.

Date: November 1977

Formats: txt json html

Obsoletes: RFC 0729

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0735

RFC 736 Telnet SUPDUP option

Authors: M.R. Crispin.

Date: October 1977

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0736

RFC 737 FTP extension: XSEN

Authors: K. Harrenstien.

Date: October 1977

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0737

RFC 738 Time server

Authors: K. Harrenstien.

Date: October 1977

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0738

RFC 739 Assigned numbers

Authors: J. Postel.

Date: November 1977

Formats: txt json html

Obsoletes: RFC 0604, RFC 0503

Obsoleted by: RFC 0750

Status: HISTORIC

DOI: 10.17487/RFC 0739

RFC 740 NETRJS Protocol

Authors: R.T. Braden.

Date: November 1977

Formats: txt html json

Obsoletes: RFC 0599

Status: HISTORIC

DOI: 10.17487/RFC 0740

RFC 741 Specifications for the Network Voice Protocol (NVP)

Authors: D. Cohen.

Date: November 1977

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0741

RFC 742 NAME/FINGER Protocol

Authors: K. Harrenstien.

Date: December 1977

Formats: txt json html

Obsoleted by: RFC 1288, RFC 1196, RFC 1194

Status: UNKNOWN

DOI: 10.17487/RFC 0742

RFC 743 FTP extension: XRSQ/XRCP

Authors: K. Harrenstien.

Date: December 1977

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0743

RFC 744 MARS - a Message Archiving and Retrieval Service

Authors: J. Sattley.

Date: January 1978

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0744

RFC 745 JANUS interface specifications

Authors: M. Beeler.

Date: March 1978

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0745

RFC 746 SUPDUP graphics extension

Authors: R. Stallman.

Date: March 1978

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0746

RFC 747 Recent extensions to the SUPDUP Protocol

Authors: M.R. Crispin.

Date: March 1978

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0747

RFC 748 Telnet randomly-lose option

Authors: M.R. Crispin.

Date: 1 April 1978

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0748

RFC 749 Telnet SUPDUP-Output option

Authors: B. Greenberg.

Date: September 1978

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0749

RFC 750 Assigned numbers

Authors: J. Postel.

Date: September 1978

Formats: txt html json

Obsoletes: RFC 0739

Obsoleted by: RFC 0755

Status: HISTORIC

DOI: 10.17487/RFC 0750

RFC 751 Survey of FTP mail and MLFL

Authors: P.D. Lebling.

Date: December 1978

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0751

RFC 752 Universal host table

Authors: M.R. Crispin.

Date: January 1979

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0752

RFC 753 Internet Message Protocol

Authors: J. Postel.

Date: March 1979

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0753

RFC 754 Out-of-net host addresses for mail

Authors: J. Postel.

Date: April 1979

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0754

RFC 755 Assigned numbers

Authors: J. Postel.

Date: May 1979

Formats: txt html json

Obsoletes: RFC 0750

Obsoleted by: RFC 0758

Status: HISTORIC

DOI: 10.17487/RFC 0755

RFC 756 NIC name server - a datagram-based information utility

Authors: J.R. Pickens, E.J. Feinler, J.E. Mathis.

Date: July 1979

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0756

RFC 757 Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems

Authors: D.P. Deutsch.

Date: September 1979

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0757

RFC 758 Assigned numbers

Authors: J. Postel.

Date: August 1979

Formats: txt html json

Obsoletes: RFC 0755

Obsoleted by: RFC 0762

Status: HISTORIC

DOI: 10.17487/RFC 0758

RFC 759 Internet Message Protocol

Authors: J. Postel.

Date: August 1980

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0759

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 761 DoD standard Transmission Control Protocol

Authors: J. Postel.

Date: January 1980

Formats: txt html json

Obsoleted by: RFC 0793, RFC 7805

Status: HISTORIC

DOI: 10.17487/RFC 0761

RFC 762 Assigned numbers

Authors: J. Postel.

Date: January 1980

Formats: txt json html

Obsoletes: RFC 0758

Obsoleted by: RFC 0770

Status: HISTORIC

DOI: 10.17487/RFC 0762

RFC 763 Role mailboxes

Authors: M.D. Abrams.

Date: May 1980

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0763

RFC 764 Telnet Protocol specification

Authors: J. Postel.

Date: June 1980

Formats: txt html json

Obsoleted by: RFC 0854

Status: UNKNOWN

DOI: 10.17487/RFC 0764

RFC 765 File Transfer Protocol specification

Authors: J. Postel.

Date: June 1980

Formats: txt html json

Obsoletes: RFC 0542

Obsoleted by: RFC 0959

Status: UNKNOWN

DOI: 10.17487/RFC 0765

RFC 766 Internet Protocol Handbook: Table of contents

Authors: J. Postel.

Date: July 1980

Formats: txt json html

Obsoleted by: RFC 0774

Status: UNKNOWN

DOI: 10.17487/RFC 0766

RFC 767 Structured format for transmission of multi-media documents

Authors: J. Postel.

Date: August 1980

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0767

RFC 768 User Datagram Protocol

Authors: J. Postel.

Date: August 1980

Formats: txt html json

Also: STD 0006

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0768

RFC 769 Rapicom 450 facsimile file format

Authors: J. Postel.

Date: September 1980

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0769

RFC 770 Assigned numbers

Authors: J. Postel.

Date: September 1980

Formats: txt html json

Obsoletes: RFC 0762

Obsoleted by: RFC 0776

Status: HISTORIC

DOI: 10.17487/RFC 0770

RFC 771 Mail transition plan

Authors: V.G. Cerf, J. Postel.

Date: September 1980

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0771

RFC 772 Mail Transfer Protocol

Authors: S. Sluizer, J. Postel.

Date: September 1980

Formats: txt json html

Obsoleted by: RFC 0780

Status: UNKNOWN

DOI: 10.17487/RFC 0772

RFC 773 Comments on NCP/TCP mail service transition strategy

Authors: V.G. Cerf.

Date: October 1980

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0773

RFC 774 Internet Protocol Handbook: Table of contents

Authors: J. Postel.

Date: October 1980

Formats: txt html json

Obsoletes: RFC 0766

Status: UNKNOWN

DOI: 10.17487/RFC 0774

RFC 775 Directory oriented FTP commands

Authors: D. Mankins, D. Franklin, A.D. Owen.

Date: December 1980

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0775

RFC 776 Assigned numbers

Authors: J. Postel.

Date: January 1981

Formats: txt json html

Obsoletes: RFC 0770

Obsoleted by: RFC 0790

Status: HISTORIC

DOI: 10.17487/RFC 0776

RFC 777 Internet Control Message Protocol

Authors: J. Postel.

Date: April 1981

Formats: txt json html

Obsoleted by: RFC 0792

Updates: RFC 0760

Status: UNKNOWN

DOI: 10.17487/RFC 0777

RFC 778 DCNET Internet Clock Service

Authors: D.L. Mills.

Date: April 1981

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0778

RFC 779 Telnet send-location option

Authors: E. Killian.

Date: April 1981

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0779

RFC 780 Mail Transfer Protocol

Authors: S. Sluizer, J. Postel.

Date: May 1981

Formats: txt html json

Obsoletes: RFC 0772

Obsoleted by: RFC 0788

Status: UNKNOWN

DOI: 10.17487/RFC 0780

RFC 781 Specification of the Internet Protocol (IP) timestamp option

Authors: Z. Su.

Date: May 1981

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0781

RFC 782 Virtual Terminal management model

Authors: J. Nabielsky, A.P. Skelton.

Date: January 1981

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0782

RFC 783 TFTP Protocol (revision 2)

Authors: K.R. Sollins.

Date: June 1981

Formats: txt json html

Obsoletes: IEN133

Obsoleted by: RFC 1350

Status: UNKNOWN

DOI: 10.17487/RFC 0783

RFC 784 Mail Transfer Protocol: ISI TOPS20 implementation

Authors: S. Sluizer, J. Postel.

Date: July 1981

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0784

RFC 785 Mail Transfer Protocol: ISI TOPS20 file definitions

Authors: S. Sluizer, J. Postel.

Date: July 1981

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0785

RFC 786 Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface

Authors: S. Sluizer, J. Postel.

Date: July 1981

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0786

RFC 787 Connectionless data transmission survey/tutorial

Authors: A.L. Chapin.

Date: July 1981

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0787

RFC 788 Simple Mail Transfer Protocol

Authors: J. Postel.

Date: November 1981

Formats: txt html json

Obsoletes: RFC 0780

Obsoleted by: RFC 0821

Status: UNKNOWN

DOI: 10.17487/RFC 0788

RFC 789 Vulnerabilities of network control protocols: An example

Authors: E.C. Rosen.

Date: July 1981

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0789

RFC 790 Assigned numbers

Authors: J. Postel.

Date: September 1981

Formats: txt html json

Obsoletes: RFC 0776

Obsoleted by: RFC 0820

Status: HISTORIC

DOI: 10.17487/RFC 0790

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 794 Pre-emption

Authors: V.G. Cerf.

Date: September 1981

Formats: txt html json

Updates: IEN125

Status: INFORMATIONAL

DOI: 10.17487/RFC 0794

RFC 795 Service mappings

Authors: J. Postel.

Date: September 1981

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0795

RFC 796 Address mappings

Authors: J. Postel.

Date: September 1981

Formats: txt json html

Obsoletes: IEN115

Status: HISTORIC

DOI: 10.17487/RFC 0796

RFC 797 Format for Bitmap files

Authors: A.R. Katz.

Date: September 1981

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0797

RFC 798 Decoding facsimile data from the Rapicom 450

Authors: A.R. Katz.

Date: September 1981

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0798

RFC 799 Internet name domains

Authors: D.L. Mills.

Date: September 1981

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0799

RFC 800 Request For Comments summary notes: 700-799

Authors: J. Postel, J. Vernon.

Date: November 1982

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 0800

This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799. This is a status report on these RFCs.

RFC 801 NCP/TCP transition plan

Authors: J. Postel.

Date: November 1981

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0801

This RFC discusses the conversion of hosts from NCP to TCP. And making available the principle services: Telnet, File Transfer, and Mail. These protocols allow all hosts in the ARPA community to share a common interprocess communication environment.

RFC 802 ARPANET 1822L Host Access Protocol

Authors: A.G. Malis.

Date: November 1981

Formats: txt html json

Obsoleted by: RFC 0851

Status: UNKNOWN

DOI: 10.17487/RFC 0802

This document proposed two major changes to the current ARPANET host access protocol. The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds). See RFCs 852 and 851.

RFC 803 Dacom 450/500 facsimile data transcoding

Authors: A. Agarwal, M.J. O'Connor, D.L. Mills.

Date: November 1981

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0803

The first part of this RFC describes in detail the Dacom 450 data compression algorithms and is an update and correction to an earlier memorandum. The second part of this RFC describes briefly the Dacom 500 data compression algorithm as used by the INTELPOST electronic-mail network under development by the US Postal Service and several foreign administrators.

RFC 804 CCITT draft recommendation T.4

Authors: International Telegraph and Telephone Consultative Committee of the International Telecommunication Union.

Date: January 1981

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0804

This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data.

RFC 805 Computer mail meeting notes

Authors: J. Postel.

Date: February 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0805

This RFC consists of notes from a meeting that was held at USC Information Sciences Institute on 11 January 1982, to discuss addressing issues in computer mail. The major conclusion reached at the meeting is to extend the "username@hostname" mailbox format to "username@host.domain", where the domain itself can be further strutured.

RFC 806 Proposed Federal Information Processing Standard: Specification for message format for computer based message systems

Authors: National Bureau of Standards.

Date: September 1981

Formats: txt html json

Obsoleted by: RFC 0841

Status: UNKNOWN

DOI: 10.17487/RFC 0806

This RFC deals with Computer Based Message systems which provides a basis for interaction between different CBMS by defining the format of messages passed between them. This RFC is replaced by RFC 841.

RFC 807 Multimedia mail meeting notes

Authors: J. Postel.

Date: February 1982

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0807

This RFC consists of notes from a meeting held at USC Information Sciences Institute on the 12th of January to discuss common interests in multimedia computer mail issues and to agree on some specific initial experiments.

RFC 808 Summary of computer mail services meeting held at BBN on 10 January 1979

Authors: J. Postel.

Date: March 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0808

This RFC is a very belated attempt to document a meeting that was held three years earlier to discuss the state of computer mail in the ARPA community and to reach some conclusions to guide the further development of computer mail systems such that a coherent total mail service would continue to be provided.

RFC 809 UCL facsimile system

Authors: T. Chang.

Date: February 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0809

This RFC describes the features of the computerised facsimile system developed in the Department of Computer Science at UCL. First its functions are considered and the related experimental work are reported. Then the disciplines for system design are discussed. Finally, the implementation of the system are described, while detailed description are given as appendices.

RFC 810 DoD Internet host table specification

Authors: E.J. Feinler, K. Harrenstien, Z. Su, V. White.

Date: March 1982

Formats: txt json html

Obsoletes: RFC 0608

Obsoleted by: RFC 0952

Status: UNKNOWN

DOI: 10.17487/RFC 0810

This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608.

RFC 811 Hostnames Server

Authors: K. Harrenstien, V. White, E.J. Feinler.

Date: March 1982

Formats: txt json html

Obsoleted by: RFC 0953

Status: UNKNOWN

DOI: 10.17487/RFC 0811

This RFC gives a description of what the Hostnames Server is and how to access it. The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the internet environment.

RFC 812 NICNAME/WHOIS

Authors: K. Harrenstien, V. White.

Date: March 1982

Formats: txt html json

Obsoleted by: RFC 0954, RFC 3912

Status: UNKNOWN

DOI: 10.17487/RFC 0812

This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it. This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory.

RFC 813 Window and Acknowledgement Strategy in TCP

Authors: D.D. Clark.

Date: July 1982

Formats: txt html json

Obsoleted by: RFC 7805

Status: HISTORIC

DOI: 10.17487/RFC 0813

This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended.

RFC 814 Name, addresses, ports, and routes

Authors: D.D. Clark.

Date: July 1982

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 0814

This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP.

RFC 815 IP datagram reassembly algorithms

Authors: D.D. Clark.

Date: July 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0815

This RFC describes an alternate approach of dealing with reassembly which reduces the bookkeeping problem to a minimum, and requires only one buffer for storage equal in size to the final datagram being reassembled, which can reassemble a datagram from any number of fragments arriving in any order with any possible pattern of overlap and duplication, and which is appropriate for almost any sort of operating system.

RFC 816 Fault isolation and recovery

Authors: D.D. Clark.

Date: July 1982

Formats: txt html json

Obsoleted by: RFC 7805

Status: HISTORIC

DOI: 10.17487/RFC 0816

This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.

RFC 817 Modularity and efficiency in protocol implementation

Authors: D.D. Clark.

Date: July 1982

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 0817

This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.

RFC 818 Remote User Telnet service

Authors: J. Postel.

Date: November 1982

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 0818

This RFC is the specification of an application protocol. Any host that implements this application level service must follow this protocol.

RFC 819 The Domain Naming Convention for Internet User Applications

Authors: Z. Su, J. Postel.

Date: August 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0819

This RFC is an attempt to clarify the generalization of the Domain Naming Convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications.

RFC 820 Assigned numbers

Authors: J. Postel.

Date: August 1982

Formats: txt json html

Obsoletes: RFC 0790

Obsoleted by: RFC 0870

Status: HISTORIC

DOI: 10.17487/RFC 0820

This RFC is an old version, see RFC 870.

RFC 821 Simple Mail Transfer Protocol

Authors: J. Postel.

Date: August 1982

Formats: txt json html

Obsoletes: RFC 0788

Obsoleted by: RFC 2821

Also: STD 0010

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0821

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772.

RFC 822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES

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 823 DARPA Internet gateway

Authors: R.M. Hinden, A. Sheltzer.

Date: September 1982

Formats: txt html json

Updates: IEN109, IEN30

Status: HISTORIC

DOI: 10.17487/RFC 0823

This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change.

RFC 824 CRONUS Virtual Local Network

Authors: W.I. MacGregor, D.C. Tappan.

Date: August 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0824

The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features. These features include a method for mapping between Internet Addresses and Local Network addresses. This is a topic of current concern in the ARPA Internet community. This note is intended to stimulate discussion. This is not a specification of an Internet Standard.

RFC 825 Request for comments on Requests For Comments

Authors: J. Postel.

Date: November 1982

Formats: txt json html

Obsoleted by: RFC 1111, RFC 1543, RFC 2223

Status: UNKNOWN

DOI: 10.17487/RFC 0825

This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future. It is in a sense a specification for RFCs.

RFC 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 828 Data communications: IFIP's international "network" of experts

Authors: K. Owen.

Date: August 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0828

This RFC is distributed to inform the ARPA Internet community of the activities of the IFIP technical committee on Data Communications, and to encourage participation in those activities.

RFC 829 Packet satellite technology reference sources

Authors: V.G. Cerf.

Date: November 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0829

This RFC describes briefly the packet satellite technology developed by the Defense Advanced Research Projects Agency and several other participating organizations in the U.K. and Norway and provides a bibliography of relevant papers for researchers interested in experimental and operational experience with this dynamic satellite-sharing technique.

RFC 830 Distributed system for Internet name service

Authors: Z. Su.

Date: October 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0830

This RFC proposes a distributed name service for DARPA Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards.

RFC 831 Backup access to the European side of SATNET

Authors: R.T. Braden.

Date: December 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0831

The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned. We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL. This proposal is not intended as a standard at this time.

RFC 832 Who talks TCP?

Authors: D. Smallberg.

Date: December 1982

Formats: txt html json

Obsoleted by: RFC 0833

Status: UNKNOWN

DOI: 10.17487/RFC 0832

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82.

RFC 833 Who talks TCP?

Authors: D. Smallberg.

Date: December 1982

Formats: txt html json

Obsoletes: RFC 0832

Obsoleted by: RFC 0834

Status: UNKNOWN

DOI: 10.17487/RFC 0833

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82.

RFC 834 Who talks TCP?

Authors: D. Smallberg.

Date: December 1982

Formats: txt json html

Obsoletes: RFC 0833

Obsoleted by: RFC 0835

Status: UNKNOWN

DOI: 10.17487/RFC 0834

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 22-Dec-82.

RFC 835 Who talks TCP?

Authors: D. Smallberg.

Date: December 1982

Formats: txt json html

Obsoletes: RFC 0834

Obsoleted by: RFC 0836

Status: UNKNOWN

DOI: 10.17487/RFC 0835

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 28-Dec-82 through 5-Jan-83.

RFC 836 Who talks TCP?

Authors: D. Smallberg.

Date: January 1983

Formats: txt html json

Obsoletes: RFC 0835

Obsoleted by: RFC 0837

Status: UNKNOWN

DOI: 10.17487/RFC 0836

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 20-Dec-82. The tests were run on 4-Jan-83 through 5-Jan-83.

RFC 837 Who talks TCP?

Authors: D. Smallberg.

Date: January 1983

Formats: txt html json

Obsoletes: RFC 0836

Obsoleted by: RFC 0838

Status: UNKNOWN

DOI: 10.17487/RFC 0837

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 11-Jan-83.

RFC 838 Who talks TCP?

Authors: D. Smallberg.

Date: January 1983

Formats: txt json html

Obsoletes: RFC 0837

Obsoleted by: RFC 0839

Status: UNKNOWN

DOI: 10.17487/RFC 0838

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 18-Jan-83.

RFC 839 Who talks TCP?

Authors: D. Smallberg.

Date: January 1983

Formats: txt json html

Obsoletes: RFC 0838

Obsoleted by: RFC 0842

Status: UNKNOWN

DOI: 10.17487/RFC 0839

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 25-Jan-83.

RFC 840 Official protocols

Authors: J. Postel.

Date: April 1983

Formats: txt html json

Obsoleted by: RFC 0880

Status: HISTORIC

DOI: 10.17487/RFC 0840

This RFC has been revised, see RFC 880.

RFC 841 Specification for message format for Computer Based Message Systems

Authors: National Bureau of Standards.

Date: January 1983

Formats: txt html json

Obsoletes: RFC 0806

Status: UNKNOWN

DOI: 10.17487/RFC 0841

This RFC is FIPS 98. The purpose of distributing this document as an RFC is to make it easily accessible to the ARPA research community. This RFC does not specify a standard for the ARPA Internet. Obsoletes RFC 806.

RFC 842 Who talks TCP? - survey of 1 February 83

Authors: D. Smallberg.

Date: February 1983

Formats: txt json html

Obsoletes: RFC 0839

Obsoleted by: RFC 0843

Status: UNKNOWN

DOI: 10.17487/RFC 0842

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA.

RFC 843 Who talks TCP? - survey of 8 February 83

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 844 Who talks ICMP, too? - Survey of 18 February 1983

Authors: R. Clements.

Date: February 1983

Formats: txt html json

Updates: RFC 0843

Status: UNKNOWN

DOI: 10.17487/RFC 0844

This survey determines how many hosts are able to respond to TELENET connections from a user at a class C site. This requires, in addition to IP and TCP, participation in gateway routing via ICMP and handling of Class C addresses. The list of hosts was taken from RFC 843, extracting only those hosts which are listed there as accepting TELNET connection. The tests were run on 18-Feb-83.

RFC 845 Who talks TCP? - survey of 15 February 1983

Authors: D. Smallberg.

Date: February 1983

Formats: txt html json

Obsoletes: RFC 0843

Obsoleted by: RFC 0846

Status: UNKNOWN

DOI: 10.17487/RFC 0845

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 from ISI-VAXA.ARPA.

RFC 846 Who talks TCP? - survey of 22 February 1983

Authors: D. Smallberg.

Date: February 1983

Formats: txt json html

Obsoletes: RFC 0845

Obsoleted by: RFC 0847

Status: UNKNOWN

DOI: 10.17487/RFC 0846

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83 from ISI-VAXA.ARPA.

RFC 847 Summary of Smallberg surveys

Authors: A. Westine, D. Smallberg, J. Postel.

Date: February 1983

Formats: txt json html

Obsoletes: RFC 0846

Status: UNKNOWN

DOI: 10.17487/RFC 0847

This is a summary of the surveys of Telnet, FTP and Mail (SMTP) servers conducted by David Smallberg in December 1982, January and February 1983 as reported in RFC 832-843, 845-846. This memo extracts the number of hosts that accepted the connection to their server for each of Telnet, FTP, and SMTP, and compares it to the total host in the Internet (not counting TACs or ECHOS).

RFC 848 Who provides the "little" TCP services?

Authors: D. Smallberg.

Date: March 1983

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0848

This RFC lists those hosts which provide any of these "little" TCP services: The list of hosts were taken from the NIC hostname table of 24-Feb-83. The tests were run on February 23 and 24, and March 3 and 5 from ISI-VAXA.ARPA.

RFC 849 Suggestions for improved host table distribution

Authors: M.R. Crispin.

Date: May 1983

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0849

This RFC actually is a request for comments. The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future. None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the adoption of standards.

RFC 850 Standard for interchange of USENET messages

Authors: M.R. Horton.

Date: June 1983

Formats: txt html json

Obsoleted by: RFC 1036

Status: UNKNOWN

DOI: 10.17487/RFC 0850

This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on.

RFC 851 ARPANET 1822L Host Access Protocol

Authors: A.G. Malis.

Date: April 1983

Formats: txt html json

Obsoletes: RFC 0802

Obsoleted by: RFC 0878

Status: UNKNOWN

DOI: 10.17487/RFC 0851

This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. Obsoletes RFC 802.

RFC 852 ARPANET short blocking feature

Authors: A.G. Malis.

Date: April 1983

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0852

This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer. This Feature is a replacement of the ARPANET non-blocking host interface, which was never implemented, and will be available to hosts using either the 1822 or 1822L Host Access Protocol. This RFC is also being presented as a solicitation of comments on the Short Blocking Feature, especially from host network software implementers and maintainers.

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 855 Telnet Option Specifications

Authors: J. Postel, J.K. Reynolds.

Date: May 1983

Formats: txt html json

Obsoletes: NIC_18640

Also: STD 0008

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0855

This memo specifies the general form for Telnet options and the directions for their specification. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651, NIC 18640.

RFC 856 Telnet Binary Transmission

Authors: J. Postel, J. Reynolds.

Date: May 1983

Formats: txt json html

Obsoletes: NIC_15389

Also: STD 0027

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0856

This Telnet Option enables a binary data mode between the Telnet modules. 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 15389.

RFC 857 Telnet Echo Option

Authors: J. Postel, J. Reynolds.

Date: May 1983

Formats: txt json html

Obsoletes: NIC_15390

Also: STD 0028

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0857

This Telnet Option enables remote echoing by the other Telnet module. 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 15390.

RFC 858 Telnet Suppress Go Ahead Option

Authors: J. Postel, J. Reynolds.

Date: May 1983

Formats: txt html json

Obsoletes: NIC_15392

Also: STD 0029

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0858

This Telnet Option disables the exchange of go-ahead signals between the Telnet modules. 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 15392.

RFC 859 Telnet Status Option

Authors: J. Postel, J. Reynolds.

Date: May 1983

Formats: txt html json

Obsoletes: RFC 0651

Also: STD 0030

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0859

This Telnet Option provides a way to determine the other Telnet module's view of the status of options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651 (NIC 31154).

RFC 860 Telnet Timing Mark Option

Authors: J. Postel, J. Reynolds.

Date: May 1983

Formats: txt html json

Obsoletes: NIC_16238

Also: STD 0031

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0860

This Telnet Option provides a way to check the roundtrip path between two Telnet modules. 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 16238.

RFC 861 Telnet Extended Options: List Option

Authors: J. Postel, J. Reynolds.

Date: May 1983

Formats: txt html json

Obsoletes: NIC_16239

Also: STD 0032

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0861

This Telnet Option provides a mechanism for extending the set of possible options. 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 16239.

RFC 862 Echo Protocol

Authors: J. Postel.

Date: May 1983

Formats: txt json html

Also: STD 0020

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0862

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Echo Protocol are expected to adopt and implement this standard. The Echo service simply sends back to the originating source any data it receives.

RFC 863 Discard Protocol

Authors: J. Postel.

Date: May 1983

Formats: txt json html

Also: STD 0021

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0863

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Discard Protocol are expected to adopt and implement this standard. The Discard service simply throws away any data it receives.

RFC 864 Character Generator Protocol

Authors: J. Postel.

Date: May 1983

Formats: txt html json

Also: STD 0022

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0864

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Character Generator Protocol are expected to adopt and implement this standard. The Character Generator service simply sends data without regard to the input.

RFC 865 Quote of the Day Protocol

Authors: J. Postel.

Date: May 1983

Formats: txt html json

Also: STD 0023

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0865

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard. The Quote of the Day service simply sends a short message without regard to the input.

RFC 866 Active users

Authors: J. Postel.

Date: May 1983

Formats: txt json html

Also: STD 0024

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0866

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement an Active Users Protocol are expected to adopt and implement this standard. The Active Users service simply sends a list of the currently active users on the host without regard to the input.

RFC 867 Daytime Protocol

Authors: J. Postel.

Date: May 1983

Formats: txt json html

Also: STD 0025

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0867

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Daytime Protocol are expected to adopt and implement this standard. The Daytime service simply sends the current date and time as a character string without regard to the input.

RFC 868 Time Protocol

Authors: J. Postel, K. Harrenstien.

Date: May 1983

Formats: txt html json

Also: STD 0026

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0868

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Time Protocol are expected to adopt and implement this standard. This protocol provides a site-independent, machine readable date and time. The Time service sends back to the originating source the time in seconds since midnight on January first 1900.

RFC 869 Host Monitoring Protocol

Authors: R. Hinden.

Date: December 1983

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0869

This RFC specifies the Host Monitoring Protocol used to collect information from various types of hosts in the Internet. Designers of Internet communications software are encouraged to consider this protocol as a means of monitoring the behavior of their creations.

RFC 870 Assigned numbers

Authors: J.K. Reynolds, J. Postel.

Date: October 1983

Formats: txt html json

Obsoletes: RFC 0820

Obsoleted by: RFC 0900

Status: HISTORIC

DOI: 10.17487/RFC 0870

This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604.

RFC 871 Perspective on the ARPANET reference model

Authors: M.A. Padlipsky.

Date: September 1982

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0871

This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA Internet Working Group, and private conversations over the intervening years. Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts.

RFC 872 TCP-on-a-LAN

Authors: M.A. Padlipsky.

Date: September 1982

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 0872

This memo attacks the notion that TCP cannot be appropriate for use on a Local Area Network. Originally published as M82-48 by the MITRE Corporation, Bedford Massachusetts.

RFC 873 Illusion of vendor support

Authors: M.A. Padlipsky.

Date: September 1982

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0873

This memo takes issue with the claim that international standards in computer protocols presently provide a basis for low cost vendor supported protocol implementations. Originally published as M82-49 by the MITRE Corporation, Bedford, Massachusetts.

RFC 874 Critique of X.25

Authors: M.A. Padlipsky.

Date: September 1982

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0874

This RFC is an analysis of X.25 pointing out some problems in the conceptual model, particularly the conflict between the interface aspects and the end-to-end aspects. The memo also touches on security, and implementation issues. Originally published as M82-50 by the MITRE Corporation, Bedford, Massachusetts.

RFC 875 Gateways, architectures, and heffalumps

Authors: M.A. Padlipsky.

Date: September 1982

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0875

This RFC is a discussion about the role of gateways in an internetwork, especially the problems of translating or mapping protocols between different protocol suites. The discussion notes possible functionality mis-matches, undesirable routing "singularity points", flow control issues, and high cost of translating gateways. Originally published as M82-51 by the MITRE Corporation, Bedford, Massachusetts.

RFC 876 Survey of SMTP implementations

Authors: D. Smallberg.

Date: September 1983

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0876

This RFC is a survey of implementation status. It does not specify an official protocol, but rather notes the status of implementation of aspects of a protocol. It is expected that the status of the hosts reported on will change. This information must be treated as a snapshot of the state of these implemetations.

RFC 877 Standard for the transmission of IP datagrams over public data networks

Authors: J.T. Korb.

Date: September 1983

Formats: txt json html

Obsoleted by: RFC 1356

Status: UNKNOWN

DOI: 10.17487/RFC 0877

This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks.

RFC 878 ARPANET 1822L Host Access Protocol

Authors: A.G. Malis.

Date: December 1983

Formats: txt html json

Obsoletes: RFC 0851

Status: UNKNOWN

DOI: 10.17487/RFC 0878

This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other.

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 880 Official protocols

Authors: J.K. Reynolds, J. Postel.

Date: October 1983

Formats: txt html json

Obsoletes: RFC 0840

Obsoleted by: RFC 0901

Status: HISTORIC

DOI: 10.17487/RFC 0880

This RFC identifies the documents specifying the official protocols used in the ARPA Internet. Annotations identify any revisions or changes planned. Obsoletes RFC 840.

RFC 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 884 Telnet terminal type option

Authors: M. Solomon, E. Wimmers.

Date: December 1983

Formats: txt html json

Obsoleted by: RFC 0930

Status: UNKNOWN

DOI: 10.17487/RFC 0884

This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol.

RFC 885 Telnet end of record option

Authors: J. Postel.

Date: December 1983

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0885

This RFC specifies a standard for the ARPA Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections.

RFC 886 Proposed standard for message header munging

Authors: M.T. Rose.

Date: December 1983

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0886

This RFC specifies a draft standard for the ARPA Internet community. It describes the rules to be used when transforming mail from the conventions of one message system to those of another message system. In particular, the treatment of header fields, and recipient addresses is specified.

RFC 887 Resource Location Protocol

Authors: M. Accetta.

Date: December 1983

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 0887

This RFC specifies a draft standard for the ARPA Internet community. It describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet.

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 889 Internet Delay Experiments

Authors: D.L. Mills.

Date: December 1983

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 0889

This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation. This memo is both a status report on the Internet and advice to TCP implementers.

RFC 890 Exterior Gateway Protocol implementation schedule

Authors: J. Postel.

Date: February 1984

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0890

This memo is a policy statement on the implementation of the Exterior Gateway Protocol in the Internet. This is an official policy statement of ICCB and DARPA. After 1-Aug-84 there shall be no dumb gateways in the Internet. Every gateway must be a member of some autonomous system. Some gateway of each autonomous system must exchange routing information with some gateway of the core autonomous system using the Exterior Gateway Protocol.

RFC 891 DCN Local-Network Protocols

Authors: D.L. Mills.

Date: December 1983

Formats: txt html json

Also: STD 0044

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0891

This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network. These procedures may be of interest to the designers and implementers of other local networks.

RFC 892 ISO Transport Protocol specification

Authors: International Organization for Standardization.

Date: December 1983

Formats: txt json html

Obsoleted by: RFC 0905

Status: UNKNOWN

DOI: 10.17487/RFC 0892

This is a draft version of the transport protocol being standardized by the ISO. This version also appeared in the ACM SIGCOMM Computer Communication Review (V.12, N.3-4) July-October 1982. This version is now out of date.

RFC 893 Trailer encapsulations

Authors: S. Leffler, M.J. Karels.

Date: April 1984

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0893

This RFC discusses the motivation for use of "trailer encapsulations" on local-area networks and describes the implementation of such an encapsulation on various media. This document is for information only. This is NOT an official protocol for the ARPA Internet community.

RFC 894 A Standard for the Transmission of IP Datagrams over Ethernet Networks

Authors: C. Hornig.

Date: April 1984

Formats: txt html json

Also: STD 0041

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0894

This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Ethernet. This RFC specifies a standard protocol for the ARPA-Internet community.

RFC 895 Standard for the transmission of IP datagrams over experimental Ethernet networks

Authors: J. Postel.

Date: April 1984

Formats: txt html json

Also: STD 0042

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0895

This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Experimental Ethernet. This RFC specifies a standard protocol for the ARPA Internet community.

RFC 896 Congestion Control in IP/TCP Internetworks

Authors: J. Nagle.

Date: January 1984

Formats: txt json html

Obsoleted by: RFC 7805

Status: HISTORIC

DOI: 10.17487/RFC 0896

This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards.

RFC 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 898 Gateway special interest group meeting notes

Authors: R.M. Hinden, J. Postel, M. Muuss, J.K. Reynolds.

Date: April 1984

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0898

This memo is a report on the Gateway Special Interest Group Meeting that was held at ISI on 28 and 29 February 1984. Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted the meeting. Approximately 35 gateway designers and implementors attended. These notes are based on the recollections of Jon Postel and Mike Muuss. Under each topic area are Jon Postel's brief notes, and additional details from Mike Muuss. This memo is a report on a meeting. No conclusions, decisions, or policy statements are documented in this note.

RFC 899 Request For Comments summary notes: 800-899

Authors: J. Postel, A. Westine.

Date: May 1984

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 0899

RFC 900 Assigned Numbers

Authors: J.K. Reynolds, J. Postel.

Date: June 1984

Formats: txt html json

Obsoletes: RFC 0870

Obsoleted by: RFC 0923

Status: HISTORIC

DOI: 10.17487/RFC 0900

This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997.

RFC 901 Official ARPA-Internet protocols

Authors: J.K. Reynolds, J. Postel.

Date: June 1984

Formats: txt html json

Obsoletes: RFC 0880

Obsoleted by: RFC 0924

Status: UNKNOWN

DOI: 10.17487/RFC 0901

This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991.

RFC 902 ARPA Internet Protocol policy

Authors: J.K. Reynolds, J. Postel.

Date: July 1984

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0902

The purpose of this memo is to explain how protocol standards are adopted for the ARPA-Internet and the DARPA research community. There are three important aspects to be discussed: the process, the authority, and the complex relationship between the DARPA community and the DDN community. This memo is a policy statement on how protocols become official standards for the ARPA-Internet and the DARPA research community. This is an official policy statement of the ICCB and the DARPA.

RFC 903 A Reverse Address Resolution Protocol

Authors: R. Finlayson, T. Mann, J.C. Mogul, M. Theimer.

Date: June 1984

Formats: txt json html

Also: STD 0038

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0903

This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements.

RFC 904 Exterior Gateway Protocol formal specification

Authors: D.L. Mills.

Date: April 1984

Formats: txt html json

Updates: RFC 0827, RFC 0888

Status: HISTORIC

DOI: 10.17487/RFC 0904

RFC-904 is the specification of the Exterior Gateway Protocol (EGP). This memo updates portions of RFC-888 and RFC-827. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet.

RFC 905 ISO Transport Protocol specification ISO DP 8073

Authors: ISO.

Date: April 1984

Formats: txt html json

Obsoletes: RFC 0892

Status: UNKNOWN

DOI: 10.17487/RFC 0905

This is the current specification of the ISO Transport Protocol. This document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695. This is the specification currently being voted on in ISO as a Draft International Standard (DIS). This document is distributed as an RFC for your information only, it does not specify a standard for the ARPA-Internet or DARPA research community. Our thanks to Alex McKenzie of BBN for making this online version available. Please note the size of this document, the file contains 258,729 characters.

RFC 906 Bootstrap loading using TFTP

Authors: R. Finlayson.

Date: June 1984

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0906

It is often convenient to be able to bootstrap a computer system from a communications network. This RFC proposes the use of the IP TFTP protocol for bootstrap loading in this case.

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 909 Loader Debugger Protocol

Authors: C. Welles, W. Milliken.

Date: July 1984

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 0909

The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.

RFC 910 Multimedia mail meeting notes

Authors: H.C. Forsdick.

Date: August 1984

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0910

This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment). The meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems. Representatives were present from BBN, ISI, SRI and Linkabit.

RFC 911 EGP Gateway under Berkeley UNIX 4.2

Authors: P. Kirton.

Date: August 1984

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0911

This memo describes an implementation of the Exterior Gateway Protocol (EGP) (in that sense it is a status report). The memo also discusses some possible extentions and some design issues (in that sense it is an invitation for further discussion).

RFC 912 Authentication service

Authors: M. St. Johns.

Date: September 1984

Formats: txt json html

Obsoleted by: RFC 0931

Status: UNKNOWN

DOI: 10.17487/RFC 0912

This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server.

RFC 913 Simple File Transfer Protocol

Authors: M. Lottor.

Date: September 1984

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 0913

This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author.

RFC 914 Thinwire protocol for connecting personal computers to the Internet

Authors: D.J. Farber, G. Delp, T.M. Conte.

Date: September 1984

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0914

This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards.

RFC 915 Network mail path service

Authors: M.A. Elvy, R. Nedved.

Date: December 1984

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0915

This RFC proposed a new service for the ARPA-Internet community and requests discussion and suggestions for improvements. The network mail path service fills the current need of people to determine mailbox addresses for hosts that are not part of the ARPA-Internet but can be reached by one or more relay hosts that have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, etc. Anyone can use the service if they have TCP/TELENET to one of the hosts with a mail path server.

RFC 916 Reliable Asynchronous Transfer Protocol (RATP)

Authors: G.G. Finn.

Date: October 1984

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 0916

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use.

RFC 917 Internet subnets

Authors: J.C. Mogul.

Date: October 1984

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0917

This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing. A subnet of an Internet network is a logically visible sub-section 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 RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 918 Post Office Protocol

Authors: J.K. Reynolds.

Date: October 1984

Formats: txt html json

Obsoleted by: RFC 0937

Status: UNKNOWN

DOI: 10.17487/RFC 0918

This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP.

RFC 919 Broadcasting Internet Datagrams

Authors: J.C. Mogul.

Date: October 1984

Formats: txt html json

Also: STD 0005

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0919

This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 920 Domain requirements

Authors: J. Postel, J.K. Reynolds.

Date: October 1984

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0920

This memo states the requirements on establishing a Domain, and introduces the limited set of top level domains. This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA.

RFC 921 Domain name system implementation schedule - revised

Authors: J. Postel.

Date: October 1984

Formats: txt html json

Updates: RFC 0897

Status: UNKNOWN

DOI: 10.17487/RFC 0921

This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is an update of RFC-881, and RFC-897. This is an official policy statement of the IAB and the DARPA. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The explanation of how this system works is to be found in the references.

RFC 922 Broadcasting Internet datagrams in the presence of subnets

Authors: J.C. Mogul.

Date: October 1984

Formats: txt json html

Also: STD 0005

Status: INTERNET STANDARD

DOI: 10.17487/RFC 0922

We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 923 Assigned numbers

Authors: J.K. Reynolds, J. Postel.

Date: October 1984

Formats: txt json html

Obsoletes: RFC 0900

Obsoleted by: RFC 0943

Status: HISTORIC

DOI: 10.17487/RFC 0923

This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997.

RFC 924 Official ARPA-Internet protocols for connecting personal computers to the Internet

Authors: J.K. Reynolds, J. Postel.

Date: October 1984

Formats: txt html json

Obsoletes: RFC 0901

Obsoleted by: RFC 0944

Status: UNKNOWN

DOI: 10.17487/RFC 0924

This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

RFC 925 Multi-LAN address resolution

Authors: J. Postel.

Date: October 1984

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0925

The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. In RFC-917 Jeffery Mogul makes a case for the use of "explicit subnets" in a multi-LAN environment. The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network. In this note I urge another approach: the use of "transparent subnets" supported by a multi-LAN extension of the Address Resolution Protocol. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 926 Protocol for providing the connectionless mode network services

Authors: International Organization for Standardization.

Date: December 1984

Formats: txt json html

Obsoleted by: RFC 0994

Status: UNKNOWN

DOI: 10.17487/RFC 0926

This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet.

RFC 927 TACACS user identification Telnet option

Authors: B.A. Anderson.

Date: December 1984

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0927

The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 928 Introduction to proposed DoD standard H-FP

Authors: M.A. Padlipsky.

Date: December 1984

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0928

The broad outline of the Host-Front End Protocol introduced here and described in RFC-929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel. It is the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of "standard". Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 929 Proposed Host-Front End Protocol

Authors: J. Lilienkamp, R. Mandell, M.A. Padlipsky.

Date: December 1984

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0929

The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 930 Telnet terminal type option

Authors: M. Solomon, E. Wimmers.

Date: January 1985

Formats: txt html json

Obsoletes: RFC 0884

Obsoleted by: RFC 1091

Status: UNKNOWN

DOI: 10.17487/RFC 0930

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation.

RFC 931 Authentication server

Authors: M. St. Johns.

Date: January 1985

Formats: txt html json

Obsoletes: RFC 0912

Obsoleted by: RFC 1413

Status: UNKNOWN

DOI: 10.17487/RFC 0931

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned.

RFC 932 Subnetwork addressing scheme

Authors: D.D. Clark.

Date: January 1985

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0932

This RFC proposes an alternative addressing scheme for subnets which, in most cases, requires no modification to host software whatsoever. The drawbacks of this scheme are that the total number of subnets in any one network are limited, and that modification is required to all gateways.

RFC 933 Output marking Telnet option

Authors: S. Silverman.

Date: January 1985

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0933

This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet.

RFC 934 Proposed standard for message encapsulation

Authors: M.T. Rose, E.A. Stefferud.

Date: January 1985

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0934

This memo concerns itself with message forwarding. Forwarding can be thought of as encapsulating one or more messages inside another. Although this is useful for transfer of past correspondence to new recipients, without a decapsulation process (which this memo terms "bursting"), the forwarded messages are of little use to the recipients because they can not be distributed, forwarded, replied-to, or otherwise processed as separate individual messages. In order to burst a message it is necessary to know how the component messages were encapsulated in the draft. At present there is no unambiguous standard for interest group digests. This RFC proposes a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 935 Reliable link layer protocols

Authors: J.G. Robinson.

Date: January 1985

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0935

This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos. The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds. The suggested protocol uses the methods of existing national and international data link layer standards. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 936 Another Internet subnet addressing scheme

Authors: M.J. Karels.

Date: February 1985

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0936

There have been several proposals for schemes to allow the use of a single Internet network number to refer to a collection of physical networks under common administration which are reachable from the rest of the Internet by a common route. Such schemes allow a simplified view of an otherwise complicated topology from hosts and gateways outside of this collection. They allow the complexity of the number and type of these networks, and routing to them, to be localized. Additions and changes in configuration thus cause no detectable change, and no interruption of service, due to slow propagation of routing and other information outside of the local environment. These schemes also simplify the administration of the network, as changes do not require allocation of new network numbers for each new cable installed. This proposal discusses an alternative scheme, one that has been in use at the University of California, Berkeley since April 1984. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 937 Post Office Protocol: Version 2

Authors: M. Butler, J. Postel, D. Chase, J. Goldberger, J.K. Reynolds.

Date: February 1985

Formats: txt json html

Obsoletes: RFC 0918

Status: HISTORIC

DOI: 10.17487/RFC 0937

This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918.

RFC 938 Internet Reliable Transaction Protocol functional and interface specification

Authors: T. Miller.

Date: February 1985

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 0938

This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 939 Executive summary of the NRC report on transport protocols for Department of Defense data networks

Authors: National Research Council.

Date: February 1985

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0939

This RFC reproduces the material from the "front pages" of the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). The point of this RFC is to make the text of the Executive Summary widely available in a timely way. The order of presentation has been altered, and the pagination changed. This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community.

RFC 940 Toward an Internet standard scheme for subnetting

Authors: Gateway Algorithms and Data Structures Task Force.

Date: April 1985

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0940

Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways). This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet.

RFC 941 Addendum to the network service definition covering network layer addressing

Authors: International Organization for Standardization.

Date: April 1985

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0941

This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address). The Network Address defined in this Addendum is the address that appears in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters, and in the primitives of the connectionless-mode Network Service as the source address and destination address parameters. This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet.

RFC 942 Transport protocols for Department of Defense data networks

Authors: National Research Council.

Date: February 1985

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0942

This RFC reproduces the National Research Council report resulting from a study of the DoD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).

RFC 943 Assigned numbers

Authors: J.K. Reynolds, J. Postel.

Date: April 1985

Formats: txt html json

Obsoletes: RFC 0923

Obsoleted by: RFC 0960

Status: HISTORIC

DOI: 10.17487/RFC 0943

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.

RFC 944 Official ARPA-Internet protocols

Authors: J.K. Reynolds, J. Postel.

Date: April 1985

Formats: txt json html

Obsoletes: RFC 0924

Obsoleted by: RFC 0961

Status: UNKNOWN

DOI: 10.17487/RFC 0944

This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

RFC 945 DoD statement on the NRC report

Authors: J. Postel.

Date: May 1985

Formats: txt json html

Obsoleted by: RFC 1039

Status: UNKNOWN

DOI: 10.17487/RFC 0945

In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only.

RFC 946 Telnet terminal location number option

Authors: R. Nedved.

Date: May 1985

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0946

Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 947 Multi-network broadcasting within the Internet

Authors: K. Lebowitz, D. Mankins.

Date: June 1985

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0947

This RFC describes the extension of a network's broadcast domain to include more than one physical network through the use of a broadcast packet repeater.

RFC 948 Two methods for the transmission of IP datagrams over IEEE 802.3 networks

Authors: I. Winston.

Date: June 1985

Formats: txt json html

Obsoleted by: RFC 1042

Status: UNKNOWN

DOI: 10.17487/RFC 0948

This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 949 FTP unique-named store command

Authors: M.A. Padlipsky.

Date: July 1985

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0949

There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name istead caused the resultant file to have a unique name relative to the current directory. This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. See RFC-959.

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 953 Hostname Server

Authors: K. Harrenstien, M.K. Stahl, E.J. Feinler.

Date: October 1985

Formats: txt html json

Obsoletes: RFC 0811

Status: HISTORIC

DOI: 10.17487/RFC 0953

This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up to date.

RFC 954 NICNAME/WHOIS

Authors: K. Harrenstien, M.K. Stahl, E.J. Feinler.

Date: October 1985

Formats: txt json html

Obsoletes: RFC 0812

Obsoleted by: RFC 3912

Status: DRAFT STANDARD

DOI: 10.17487/RFC 0954

This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812.

RFC 955 Towards a transport service for transaction processing applications

Authors: R.T. Braden.

Date: September 1985

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0955

The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively. These two protocols represent points in the space of possible transport service attributes which are quite "far apart". We want to examine an important class of applications, those which perform what is often called "transaction processing". We will see that the communication needs for these applications fall into the gap "between" TCP and UDP -- neither protocol is very appropriate. This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present. The RFC is intended to spur discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements. It does not represent a standard, nor even a concrete protocol proposal.

RFC 956 Algorithms for synchronizing network clocks

Authors: D.L. Mills.

Date: September 1985

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0956

This RFC discussed clock synchronization algorithms for the ARPA-Internet community, and requests discussion and suggestions for improvements. The recent interest within the Internet community in determining accurate time from a set of mutually suspicious network clocks has been prompted by several occasions in which errors were found in usually reliable, accurate clock servers after thunderstorms which disrupted their power supply. To these sources of error should be added those due to malfunctioning hardware, defective software and operator mistakes, as well as random errors in the mechanism used to set and synchronize clocks. This report suggests a stochastic model and algorithms for computing a good estimator from time-offset samples measured between clocks connected via network links. Included in this report are descriptions of certain experiments which give an indication of the effectiveness of the algorithms.

RFC 957 Experiments in network clock synchronization

Authors: D.L. Mills.

Date: September 1985

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0957

This RFC discusses some experiments in clock synchronization in the ARPA-Internet community, and requests discussion and suggestions for improvements. One of the services frequently neglected in computer network design is a high-quality, time-of-day clock capable of generating accurate timestamps with small errors compared to one-way network delays. Such a service would be useful for tracing the progress of complex transactions, synchronizing cached data bases, monitoring network performance and isolating problems. In this memo one such clock service design will be described and its performance assessed. This design has been incorporated as an integral part of the network routing and control protocols of the Distributed Computer Network (DCnet) architecture.

RFC 958 Network Time Protocol (NTP)

Authors: D.L. Mills.

Date: September 1985

Formats: txt json html

Obsoleted by: RFC 1059, RFC 1119, RFC 1305

Status: UNKNOWN

DOI: 10.17487/RFC 0958

This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 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 960 Assigned numbers

Authors: J.K. Reynolds, J. Postel.

Date: December 1985

Formats: txt json html

Obsoletes: RFC 0943

Obsoleted by: RFC 0990

Status: HISTORIC

DOI: 10.17487/RFC 0960

This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.

RFC 961 Official ARPA-Internet protocols

Authors: J.K. Reynolds, J. Postel.

Date: December 1985

Formats: txt json html

Obsoletes: RFC 0944

Obsoleted by: RFC 0991

Status: UNKNOWN

DOI: 10.17487/RFC 0961

This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

RFC 962 TCP-4 prime

Authors: M.A. Padlipsky.

Date: November 1985

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0962

This memo is in response to Bob Braden's call for a transaction oriented protocol (RFC-955), and continues the discussion of a possible transaction oriented transport protocol. This memo does not propose a standard.

RFC 963 Some problems with the specification of the Military Standard Internet Protocol

Authors: D.P. Sidhu.

Date: November 1985

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0963

The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol. This paper points out several problems in this specification. This note also proposes solutions to these problems.

RFC 964 Some problems with the specification of the Military Standard Transmission Control Protocol

Authors: D.P. Sidhu, T. Blumer.

Date: November 1985

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 0964

The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems.

RFC 965 Format for a graphical communication protocol

Authors: L. Aguilar.

Date: December 1985

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0965

This RFC describes the requirements for a graphical format on which to base a graphical on-line communication protocol, and proposes an Interactive Graphical Communication Format using the GKSM session metafile. We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions.

RFC 966 Host groups: A multicast extension to the Internet Protocol

Authors: S.E. Deering, D.R. Cheriton.

Date: December 1985

Formats: txt html json

Obsoleted by: RFC 0988

Status: UNKNOWN

DOI: 10.17487/RFC 0966

This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. See RFC-988.

RFC 967 All victims together

Authors: M.A. Padlipsky.

Date: December 1985

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0967

This RFC proposes a new set of RFCs on how the networking code is integrated with various operating systems. It appears that this topic has not received enough exposure in the literature. Comments and suggestions are encouraged.

RFC 968 Twas the night before start-up

Authors: V.G. Cerf.

Date: December 1985

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0968

This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.

RFC 969 NETBLT: A bulk data transfer protocol

Authors: D.D. Clark, M.L. Lambert, L. Zhang.

Date: December 1985

Formats: txt json html

Obsoleted by: RFC 0998

Status: UNKNOWN

DOI: 10.17487/RFC 0969

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-998.

RFC 970 On Packet Switches With Infinite Storage

Authors: J. Nagle.

Date: December 1985

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0970

Most prior work on congestion in datagram systems focuses on buffer management. We find it illuminating to consider the case of a packet switch with infinite storage. Such a packet switch can never run out of buffers. It can, however, still become congested. The meaning of congestion in an infinite-storage system is explored. We demonstrate the unexpected result that a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets. By attacking the problem of congestion for the infinite-storage case, we discover new solutions applicable to switches with finite storage.

RFC 971 Survey of data representation standards

Authors: A.L. DeSchon.

Date: January 1986

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0971

This RFC is a comparison of several data representation standards that are currently in use. The standards discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package. No proposals in this document are intended as standards for the ARPA-Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate approach to a data representation standard, leading eventually to the adoption of an ARPA-Internet standard.

RFC 972 Password Generator Protocol

Authors: F.J. Wancho.

Date: January 1986

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0972

This RFC specifies a standard for the ARPA Internet community. The Password Generator Service (PWDGEN) provides a set of six randomly generated eight-character "words" with a reasonable level of pronounceability, using a multi-level algorithm. Hosts on the ARPA Internet that choose to implement a password generator service are expected to adopt and implement this standard.

RFC 973 Domain system changes and observations

Authors: P. Mockapetris.

Date: January 1986

Formats: txt html json

Obsoleted by: RFC 1034, RFC 1035

Updates: RFC 0882, RFC 0883

Status: UNKNOWN

DOI: 10.17487/RFC 0973

This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system.

RFC 974 Mail routing and the domain system

Authors: C. Partridge.

Date: January 1986

Formats: txt json html

Obsoleted by: RFC 2821

Also: STD 0010

Status: HISTORIC

DOI: 10.17487/RFC 0974

This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing.

RFC 975 Autonomous confederations

Authors: D.L. Mills.

Date: February 1986

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0975

This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model. The enhancements generalize the concept of core system to include multiple communities of autonomous systems, called autonomous confederations. Discussion and suggestions for improvement are requested.

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 977 Network News Transfer Protocol

Authors: B. Kantor, P. Lapsley.

Date: February 1986

Formats: txt html json

Obsoleted by: RFC 3977

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 0977

NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 978 Voice File Interchange Protocol (VFIP)

Authors: J.K. Reynolds, R. Gillman, W.A. Brackenridge, A. Witkowski, J. Postel.

Date: February 1986

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0978

The purpose of the Voice File Interchange Protocol (VFIP) is to permit the interchange of various types of speech files between different systems in the ARPA-Internet community. Suggestions for improvement are encouraged.

RFC 979 PSN End-to-End functional specification

Authors: A.G. Malis.

Date: March 1986

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0979

This memo is an updated version of BBN Report 5775, "End-to-End Functional Specification and describes important changes to the functionality of the interface between a Host and the PSN, and should be carefully reviewed by anyone involved in supporting a host on either the ARPANET or MILNET". The new End-to-End protocol (EE) is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the Packet Switch Node (PSN, also known as the IMP) to support its current and anticipated host population.

RFC 980 Protocol document order information

Authors: O.J. Jacobsen, J. Postel.

Date: March 1986

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0980

This RFC indicates how to obtain various protocol documents used in the DARPA research community. Included is an overview of the new 1985 DDN Protocol Handbook and available sources for obtaining related documents (such as DOD, ISO, and CCITT).

RFC 981 Experimental multiple-path routing algorithm

Authors: D.L. Mills.

Date: March 1986

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0981

This document introduces wiretap algorithms, which are a class of routing algorithms that compute quasi-optimum routes for stations sharing a broadcast channel, but with some stations hidden from others. The wiretapper observes the paths (source routes) used by other stations sending traffic on the channel and, using a heuristic set of factors and weights, constructs speculative paths for its own traffic. A prototype algorithm, called here the Wiretap Algorithm, has been designed for the AX.25 packet-radio channel. Its design is similar in many respects to the shortest-path-first (spf) algorithm used in the ARPANET and elsewhere, and is in fact a variation in the class of algorithms, including the Viterbi Algorithm, that construct optimum paths on a graph according to a distance computed as a weighted sum of factors assigned to the nodes and edges.
The Wiretap Algorithm differs from conventional algorithms in that it computes not only the primary route (a minimum-distance path), but also additional paths ordered by distance, which serve as alternate routes should the primary route fail. This feature is also useful for the discovery of new paths not previously observed on the channel.
Since the amateur AX.25 packet-radio channel is very active in theWashington, DC, area and carries a good deal of traffic under punishing conditions, it was considered a sufficiently heroic environment for a convincing demonstration of the prototype algorithm. It was implemented as part of an IP/TCP driver for theLSI-11 processor running the "fuzzball" operating system. The driver is connected via serial line to a 6809-based TAPR-1 processor running the WA8DED firmware, which controls the radio equipmnet in both

RFC 982 Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address

Authors: H.W. Braun.

Date: April 1986

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0982

This RFC is a draft working document of the ANSI "Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address". It provides guidance to private address administration authorities on preferred formats and semantics for the Domain Specific Part (DSP) of an NSAP address. This RFC specifies the way in which the DSP may be constructed so as to facilitate efficient address assignment. This RFC is for informational purposes only and its distribution is unlimited and does not specify a standard of the ARPA-Internet.

RFC 983 ISO transport arrives on top of the TCP

Authors: D.E. Cass, M.T. Rose.

Date: April 1986

Formats: txt html json

Obsoleted by: RFC 1006

Status: UNKNOWN

DOI: 10.17487/RFC 0983

This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged.

RFC 984 PCMAIL: A distributed mail system for personal computers

Authors: D.D. Clark, M.L. Lambert.

Date: May 1986

Formats: txt json html

Obsoleted by: RFC 0993

Status: UNKNOWN

DOI: 10.17487/RFC 0984

This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993.

RFC 985 Requirements for Internet gateways - draft

Authors: National Science Foundation, Network Technical Advisory Group.

Date: May 1986

Formats: txt json html

Obsoleted by: RFC 1009

Status: UNKNOWN

DOI: 10.17487/RFC 0985

This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification.

RFC 986 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol

Authors: R. Callon, H.W. Braun.

Date: June 1986

Formats: txt html json

Obsoleted by: RFC 1069

Status: UNKNOWN

DOI: 10.17487/RFC 0986

This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC 987 Mapping between X.400 and RFC 822

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 988 Host extensions for IP multicasting

Authors: S.E. Deering.

Date: July 1986

Formats: txt json html

Obsoletes: RFC 0966

Obsoleted by: RFC 1054, RFC 1112

Status: UNKNOWN

DOI: 10.17487/RFC 0988

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here.

RFC 989 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures

Authors: J. Linn.

Date: February 1987

Formats: txt json html

Obsoleted by: RFC 1040, RFC 1113

Status: UNKNOWN

DOI: 10.17487/RFC 0989

This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated.

RFC 990 Assigned numbers

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 991 Official ARPA-Internet protocols

Authors: J.K. Reynolds, J. Postel.

Date: November 1986

Formats: txt json html

Obsoletes: RFC 0961

Obsoleted by: RFC 1011

Status: UNKNOWN

DOI: 10.17487/RFC 0991

This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924.

RFC 992 On communication support for fault tolerant process groups

Authors: K.P. Birman, T.A. Joseph.

Date: November 1986

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 0992

This memo describes a collection of multicast communication primitives integrated with a mechanism for handling process failure and recovery. These primitives facilitate the implementation of fault-tolerant process groups, which can be used to provide distributed services in an environment subject to non-malicious crash failures.

RFC 993 PCMAIL: A distributed mail system for personal computers

Authors: D.D. Clark, M.L. Lambert.

Date: December 1986

Formats: txt html json

Obsoletes: RFC 0984

Obsoleted by: RFC 1056

Status: UNKNOWN

DOI: 10.17487/RFC 0993

This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984.

RFC 994 Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service

Authors: International Organization for Standardization.

Date: March 1986

Formats: txt json html

Obsoletes: RFC 0926

Status: UNKNOWN

DOI: 10.17487/RFC 0994

This Protocol Standard is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498). In particular, it is a protocol of the Network Layer. This Protocol may be used between network-entities in end systems or in Network Layer relay systems (or both). It provides the Connectionless-mode Network Service as defined in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1).

RFC 995 End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473

Authors: International Organization for Standardization.

Date: April 1986

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 0995

This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648). In particular, it is a protocol of the Network Layer. This Protocol permits End Systems and Intermediate Systems to exchange configuration and routing information to facilitate the operation of the routing and relaying functions of the Network Layer.

RFC 996 Statistics server

Authors: D.L. Mills.

Date: February 1987

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 0996

This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host.

RFC 997 Internet numbers

Authors: J.K. Reynolds, J. Postel.

Date: March 1987

Formats: txt html json

Obsoleted by: RFC 1020, RFC 1117

Updates: RFC 0990

Status: UNKNOWN

DOI: 10.17487/RFC 0997

This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900.

RFC 998 NETBLT: A bulk data transfer protocol

Authors: D.D. Clark, M.L. Lambert, L. Zhang.

Date: March 1987

Formats: txt json html

Obsoletes: RFC 0969

Status: EXPERIMENTAL

DOI: 10.17487/RFC 0998

This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP. This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. Obsoletes RFC-969.

RFC 999 Requests For Comments summary notes: 900-999

Authors: A. Westine, J. Postel.

Date: April 1987

Formats: txt json html

Obsoletes: RFC 0160

Obsoleted by: RFC 1000

Status: UNKNOWN

DOI: 10.17487/RFC 0999

RFC 1000 Request For Comments reference guide

Authors: J.K. Reynolds, J. Postel.

Date: August 1987

Formats: txt html json

Obsoletes: RFC 0999

Status: UNKNOWN

DOI: 10.17487/RFC 1000

This RFC Reference Guide is intended to provide a historical account by categorizing and summarizing of the Request for Comments numbers 1 through 999 issued between the years 1969-1987. These documents have been crossed referenced to indicate which RFCs are current, obsolete, or revised.

RFC 1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods

Authors: NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force.

Date: March 1987

Formats: txt html json

Also: STD 0019

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1001

This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques. Detailed specifications are found in a companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications".

RFC 1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications

Authors: NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force.

Date: March 1987

Formats: txt json html

Also: STD 0019

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1002

This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC gives the detailed specifications of the netBIOS-over-TCP packets, protocols, and defined constants and variables. A more general overview is found in a companion RFC, "Protocol Standard For NetBIOS Service on TCP/UDP Transport: Concepts and Methods".

RFC 1003 Issues in defining an equations representation standard

Authors: A.R. Katz.

Date: March 1987

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1003

This memo is intended to identify and explore issues in defining a standard for the exchange of mathematical equations. No attempt is made at a complete definition and more questions are asked than are answered. Questions about the user interface are only addressed to the extent that they affect interchange issues.

RFC 1004 Distributed-protocol authentication scheme

Authors: D.L. Mills.

Date: April 1987

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1004

The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution. The proposed solutions this document are not intended as standards for the Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards. This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between users belonging to different trust environments.

RFC 1005 ARPANET AHIP-E Host Access Protocol (enhanced AHIP)

Authors: A. Khanna, A.G. Malis.

Date: May 1987

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1005

This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol (AHIP; formerly known as 1822). These enhancements increase the size of the PSN field, allow ARPANET hosts to use logical names to address each other, allow for the communication of type-of-service information from the host to the PSN and enable the PSN to provide congestion feedback to the host on a connection basis.

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 1007 Military supplement to the ISO Transport Protocol

Authors: W. McCoy.

Date: June 1987

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1007

This document supplements the Transport Service and Protocol of the International Standards Organization (ISO), IS 8072 and IS 8073, respectively, and their formal descriptions by providing conventions, option selections and parameter values. This RFC is being distributed to members of the Internet community in order to solicit comments on the Draft Military Supplement. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.

RFC 1008 Implementation guide for the ISO Transport Protocol

Authors: W. McCoy.

Date: June 1987

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1008

This RFC is being distributed to members of the Internet community in order to solicit comments on the Implementors Guide. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.

RFC 1009 Requirements for Internet gateways

Authors: R.T. Braden, J. Postel.

Date: June 1987

Formats: txt html json

Obsoletes: RFC 0985

Obsoleted by: RFC 1812

Status: HISTORIC

DOI: 10.17487/RFC 1009

This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community.

RFC 1010 Assigned numbers

Authors: J.K. Reynolds, J. Postel.

Date: May 1987

Formats: txt html json

Obsoletes: RFC 0990

Obsoleted by: RFC 1060

Status: HISTORIC

DOI: 10.17487/RFC 1010

This memo is an official status report on the numbers used in protocols in the Internet community. It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations.

RFC 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 1012 Bibliography of Request For Comments 1 through 999

Authors: J.K. Reynolds, J. Postel.

Date: June 1987

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1012

This RFC is a reference guide for the Internet community which provides a bibliographic summary of the Request for Comments numbers 1 through 999 issued between the years 1969-1987.

RFC 1013 X Window System Protocol, version 11: Alpha update April 1987

Authors: R.W. Scheifler.

Date: June 1987

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1013

This RFC is distributed to the Internet community for information only. It does not establish an Internet standard. The X window system has been widely reviewed and tested. The Internet community is encouraged to experiment with it.

RFC 1014 XDR: External Data Representation standard

Authors: Sun Microsystems.

Date: June 1987

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1014

XDR is a standard for the description and encoding of data. It is useful for transferring data between different computer architectures. XDR fits into ISO presentation layer, and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between these two is that XDR uses implicit typing, while X.409 uses explicit typing. This RFC is distributed for information only, it does not establish a Internet standard.

RFC 1015 Implementation plan for interagency research Internet

Authors: B.M. Leiner.

Date: July 1987

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1015

This RFC proposes an Interagency Research Internet as the natural outgrowth of the current Internet. This is an "idea paper" and discussion is strongly encouraged.

RFC 1016 Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)

Authors: W. Prue, J. Postel.

Date: July 1987

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1016

The memo is intended to explore the issue of what a host could do with a source quench. The proposal is for each source host IP module to introduce some delay between datagrams sent to the same destination host. This is a "crazy idea paper" and discussion is essential.

RFC 1017 Network requirements for scientific research: Internet task force on scientific computing

Authors: B.M. Leiner.

Date: August 1987

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1017

This RFC identifies the requirements on communication networks for supporting scientific research. It proposes some specific areas for near term work, as well as some long term goals. This is an "idea" paper and discussion is strongly encouraged.

RFC 1018 Some comments on SQuID

Authors: A.M. McKenzie.

Date: August 1987

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1018

This memo is a discussion of some of the ideas expressed in RFC-1016 on Source Quench. This memo introduces the distinction of the cause of congestion in a gateway between the effects of "Funneling" and Mismatch". It is offered in the same spirit as RFC-1016; to stimulate discussion. The opinions offered are personal, not corporate, opinions.

RFC 1019 Report of the Workshop on Environments for Computational Mathematics

Authors: D. Arnon.

Date: September 1987

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1019

This memo is a report on the discussion of the representation of equations in a workshop at the ACM SIGGRAPH Conference held in Anaheim, California on 30 July 1987.

RFC 1020 Internet numbers

Authors: S. Romano, M.K. Stahl.

Date: November 1987

Formats: txt html json

Obsoletes: RFC 0997

Obsoleted by: RFC 1062, RFC 1117, RFC 1166

Status: UNKNOWN

DOI: 10.17487/RFC 1020

This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers. This RFC obsoletes RFC-997.

RFC 1021 High-level Entity Management System (HEMS)

Authors: C. Partridge, G. Trewitt.

Date: October 1987

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1021

This memo provides a general overview of the High-level Entity management system (HEMS). This system is experimental, and is currently being tested in portions of the Internet.

RFC 1022 High-level Entity Management Protocol (HEMP)

Authors: C. Partridge, G. Trewitt.

Date: October 1987

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1022

This memo presents an application protocol for managing network entities such as hosts, gateways, and front end machines. This protocol is a component of the High-level Entity Management System HEMS), described is RFC-1021. This memo also assumes a knowledge of the ISO data encoding standard, ASN.1.

RFC 1023 HEMS monitoring and control language

Authors: G. Trewitt, C. Partridge.

Date: October 1987

Formats: txt json html

Obsoleted by: RFC 1076

Status: UNKNOWN

DOI: 10.17487/RFC 1023

This RFC specifies the High-Level Entity Management System (HEMS) Monitoring and Control Language. This language defines the requests and replies used in HEMS. This memo assumes knowledge of the HEMS system described in RFC-1021, and of the ISO data encoding standard, ASN.1.

RFC 1024 HEMS variable definitions

Authors: C. Partridge, G. Trewitt.

Date: October 1987

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1024

This memo assigns instruction codes, defines object formats and object semantics for use with the High-Level Monitoring and Control Language, defined in RFC-1023. A general system has been described in previous memos (RFC-1021, RFC-1022). This system is called the High-Level Entity Management System (HEMS). This memo is provisional and the definitions are subject to change. Readers should confirm with the authors that they have the most recent version. This RFC assumes a working knowledge of the ISO data encoding standard, ASN.1, and a general understanding of the IP protocol suite.

RFC 1025 TCP and IP bake off

Authors: J. Postel.

Date: September 1987

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1025

This memo describes some of the procedures, scoring and tests used in the TCP and IP bake offs held in the early development of these protocols. These procedures and tests may still be of use in testing newly implemented TCP and IP modules.

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 1027 Using ARP to implement transparent subnet gateways

Authors: S. Carl-Mitchell, J.S. Quarterman.

Date: October 1987

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1027

This RFC describes the use of the Address Resolution Protocol (ARP) by subnet gateways to permit hosts on the connected subnets to communicate without being aware of the existence of subnets, using the technique of "Proxy ARP".

RFC 1028 Simple Gateway Monitoring Protocol

Authors: J. Davin, J.D. Case, M. Fedor, M.L. Schoffstall.

Date: November 1987

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1028

This memo defines a simple application-layer protocol by which management information for a gateway may be inspected or altered by remote users. This proposal is intended only as an interim response to immediate gateway monitoring needs.

RFC 1029 More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets

Authors: G. Parr.

Date: May 1988

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1029

This memo discusses an extension to a Bridge Protocol to detect and disclose changes in heighbouring host address parameters in a Multi-Lan system of Ethernets. The problem is one which is appearing more and more regularly as the interconnected systems grow larger on Campuses and in Commercial Institutions. This RFC suggests a protocol enhancement for the Internet community, and requests discussion and suggestions for improvements.

RFC 1030 On testing the NETBLT Protocol over divers networks

Authors: M.L. Lambert.

Date: November 1987

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1030

This memo describes the results gathered from testing NETBLT over three networks of different bandwidths and round-trip delays. The results are not complete, but the information gathered so far has not been promising. The NETBLT protocol is specified in RFC-998; this document assumes an understanding of the specification as described in RFC-998.

RFC 1031 MILNET name domain transition

Authors: W.D. Lazear.

Date: November 1987

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1031

This RFC consolidates information necessary for the implementation of domain style names throughout the DDN/MILNET Internet community. The introduction of domain style names will impact all hosts in the DDN/MILNET Internet. This RFC is designed as an aid to implementors and administrators by providing: 1) an overview of the transition process from host tables to domains, 2) a timetable for the transition, and 3) references to documentation and software relating to the domain system.

RFC 1032 Domain administrators guide

Authors: M.K. Stahl.

Date: November 1987

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1032

Domains are administrative entities that provide decentralized management of host naming and addressing. The domain-naming system is distributed and hierarchical. This memo describes procedures for registering a domain with the Network Information Center (NIC) of Defense Data Network (DDN), and offers guidelines on the establishment and administration of a domain in accordance with the requirements specified in RFC-920. It is recommended that the guidelines described in this document be used by domain administrators in the establishment and control of second-level domains. The role of the domain administrator (DA) is that of coordinator, manager, and technician. If his domain is established at the second level or lower in the tree, the domain administrator must register by interacting with the management of the domain directly above this.

RFC 1033 Domain Administrators Operations Guide

Authors: M. Lottor.

Date: November 1987

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1033

This RFC provides guidelines for domain administrators in operating a domain server and maintaining their portion of the hierarchical database. Familiarity with the domain system is assumed (see RFCs 1031, 1032, 1034, and 1035).

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 1036 Standard for interchange of USENET messages

Authors: M.R. Horton, R. Adams.

Date: December 1987

Formats: txt json html

Obsoletes: RFC 0850

Obsoleted by: RFC 5536, RFC 5537

Status: UNKNOWN

DOI: 10.17487/RFC 1036

This RFC defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is distributed as an RFC to make this information easily accessible to the Internet community. It does not specify an Internet standard.

RFC 1037 NFILE - a file access protocol

Authors: B. Greenberg, S. Keene.

Date: December 1987

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1037

This document includes a specification of the NFILE file access protocol and its underlying levels of protocol, the Token List Transport Layer and Byte Stream with Mark. The goal of this specification is to promote discussion of the ideas described here, and to encourage designers of future file protocols to take advantage of these ideas. A secondary goal is to make the specification available to sites that might benefit from implementing NFILE.

RFC 1038 Draft revised IP security option

Authors: M. St. Johns.

Date: January 1988

Formats: txt html json

Obsoleted by: RFC 1108

Status: UNKNOWN

DOI: 10.17487/RFC 1038

This memo is a pre-publication draft of the revised Internet Protocol Security Option. This RFC reflects the version as approved by the Protocol Standards Steering group, and is provided for informational purposes only. The final version of this document will be available from Navy publications and should not differ from this document in any major fashion. This document will be published as a change to the MIL- STD 1777, "Internet Protocol".

RFC 1039 DoD statement on Open Systems Interconnection protocols

Authors: D. Latham.

Date: January 1988

Formats: txt html json

Obsoletes: RFC 0945

Status: UNKNOWN

DOI: 10.17487/RFC 1039

This RFC reproduces a memorandum issued on 2-JUL-87 from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC31) to the Director of the Defense Communications Agency (DCA). This memo is distributed for information only.

RFC 1040 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures

Authors: J. Linn.

Date: January 1988

Formats: txt json html

Obsoletes: RFC 0989

Obsoleted by: RFC 1113

Status: UNKNOWN

DOI: 10.17487/RFC 1040

This RFC is the Outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This memo defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated.

RFC 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 1042 Standard for the transmission of IP datagrams over IEEE 802 networks

Authors: J. Postel, J.K. Reynolds.

Date: February 1988

Formats: txt html json

Obsoletes: RFC 0948

Also: STD 0043

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1042

This RFC specifies a standard method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on IEEE 802 Networks to allow compatible and interoperable implementations. This RFC specifies a protocol standard for the Internet community.

RFC 1043 Telnet Data Entry Terminal option: DODIIS implementation

Authors: A. Yasuda, T. Thompson.

Date: February 1988

Formats: txt html json

Updates: RFC 0732

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1043

This RFC suggests a proposed protocol on the TELNET Data Entry Terminal (DET) Option - DODIIS Implementation for the Internet community. It is intended that this specification be capatible with the specification of DET Option in RFC-732. Discussion and suggests for improvements are encouraged.

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 1045 VMTP: Versatile Message Transaction Protocol: Protocol specification

Authors: D.R. Cheriton.

Date: February 1988

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1045

This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples. This RFC describes a protocol proposed as a standard for the Internet community.

RFC 1046 Queuing algorithm to provide type-of-service for IP links

Authors: W. Prue, J. Postel.

Date: February 1988

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1046

This memo is intended to explore how Type-of-Service might be implemented in the Internet. The proposal describes a method of queuing which can provide the different classes of service. The technique also prohibits one class of service from consuming excessive resources or excluding other classes of service. This is an "idea paper" and discussion is strongly encouraged.

RFC 1047 Duplicate messages and SMTP

Authors: C. Partridge.

Date: February 1988

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1047

An examination of a synchronization problem in the Simple Mail Transfer Protocol (SMTP) is presented. This synchronization problem can cause a message to be delivered multiple times. A method for avoiding this problem is suggested. Nodding familiarity with the SMTP specification, RFC-821, is required.

RFC 1048 BOOTP vendor information extensions

Authors: P.A. Prindeville.

Date: February 1988

Formats: txt json html

Obsoleted by: RFC 1084, RFC 1395, RFC 1497, RFC 1533

Status: UNKNOWN

DOI: 10.17487/RFC 1048

This memo proposes an addition to the Bootstrap Protocol (BOOTP). Comments and suggestions for improvements are sought.

RFC 1049 Content-type header field for Internet messages

Authors: M.A. Sirbu.

Date: March 1988

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1049

This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements.

RFC 1050 RPC: Remote Procedure Call Protocol specification

Authors: Sun Microsystems.

Date: April 1988

Formats: txt json html

Obsoleted by: RFC 1057

Status: HISTORIC

DOI: 10.17487/RFC 1050

This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package. This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration. It is not an Internet standard at this time.

RFC 1051 Standard for the transmission of IP datagrams and ARP packets over ARCNET networks

Authors: P.A. Prindeville.

Date: March 1988

Formats: txt json html

Obsoleted by: RFC 1201

Status: HISTORIC

DOI: 10.17487/RFC 1051

This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET. This RFC is a standard protocol for the Internet community.

RFC 1052 IAB recommendations for the development of Internet network management standards

Authors: V.G. Cerf.

Date: April 1988

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1052

This RFC is intended to convey to the Internet community and other interested parties the recommendations of the Internet Activities Board (IAB) for the development of network management protocols for use in the TCP/IP environment. This memo does NOT, in and of itself, define or propose an Official Internet Protocol. It does reflect, however, the policy of the IAB with respect to further network management development in the short and long term.

RFC 1053 Telnet X.3 PAD option

Authors: S. Levy, T. Jacobson.

Date: April 1988

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1053

This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.

RFC 1054 Host extensions for IP multicasting

Authors: S.E. Deering.

Date: May 1988

Formats: txt json html

Obsoletes: RFC 0988

Obsoleted by: RFC 1112

Status: UNKNOWN

DOI: 10.17487/RFC 1054

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. IP multicasting is the transmission of an IP datagram to a "host group", a set hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988.

RFC 1055 Nonstandard for transmission of IP datagrams over serial lines: SLIP

Authors: J.L. Romkey.

Date: June 1988

Formats: txt json html

Also: STD 0047

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1055

The TCP/IP protocol family runs over a variety of network media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines, satellite links, and serial lines. There are standard encapsulations for IP packets defined for many of these networks, but there is no standard for serial lines. SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard.

RFC 1056 PCMAIL: A distributed mail system for personal computers

Authors: M.L. Lambert.

Date: June 1988

Formats: txt html json

Obsoletes: RFC 0993

Status: INFORMATIONAL

DOI: 10.17487/RFC 1056

This memo is a discussion of the Pcmail workstation based distributed mail system. It is identical to the discussion in RFC-993, save that a new, much simpler mail transport protocol is described. The new transport protocol is the result of continued research into ease of protocol implementation and use issues.

RFC 1057 RPC: Remote Procedure Call Protocol specification: Version 2

Authors: Sun Microsystems.

Date: June 1988

Formats: txt html json

Obsoletes: RFC 1050

Status: INFORMATIONAL

DOI: 10.17487/RFC 1057

This RFC describes a standard that Sun Microsystems and others are using, and is one we wish to propose for the Internet's consideration. This memo is not an Internet standard at this time.

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 1059 Network Time Protocol (version 1) specification and implementation

Authors: D.L. Mills.

Date: July 1988

Formats: txt json html

Obsoletes: RFC 0958

Obsoleted by: RFC 1119, RFC 1305

Status: UNKNOWN

DOI: 10.17487/RFC 1059

This memo describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical master-slave configuration synchronizes logical clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. The NTP architectures, algorithms and protocols which have evolved over several years of implementation and refinement are described in this document. The prototype system, which has been in regular operation in the Internet for the last two years, is described in an Appendix along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even the cases of failure or disruption of clocks, time servers or nets. This is a Draft Standard for an Elective protocol.

RFC 1060 Assigned numbers

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 1062 Internet numbers

Authors: S. Romano, M.K. Stahl, M. Recker.

Date: August 1988

Formats: txt html json

Obsoletes: RFC 1020

Obsoleted by: RFC 1117, RFC 1166

Status: UNKNOWN

DOI: 10.17487/RFC 1062

This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community.

RFC 1063 IP MTU discovery options

Authors: J.C. Mogul, C.A. Kent, C. Partridge, K. McCloghrie.

Date: July 1988

Formats: txt html json

Obsoleted by: RFC 1191

Status: UNKNOWN

DOI: 10.17487/RFC 1063

A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol.

RFC 1064 Interactive Mail Access Protocol: Version 2

Authors: M.R. Crispin.

Date: July 1988

Formats: txt json html

Obsoleted by: RFC 1176, RFC 1203

Status: UNKNOWN

DOI: 10.17487/RFC 1064

This memo suggests a method for workstations to dynamically access mail from a mailbox server ("respository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested.

RFC 1065 Structure and identification of management information for TCP/IP-based internets

Authors: K. McCloghrie, M.T. Rose.

Date: August 1988

Formats: txt json html

Obsoleted by: RFC 1155

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1065

This RFC provides the common definitions for the structure and identification of management information for TCP/IP-based internets. In particular, together with its companion memos, which describe the initial management information base along with the initial network management protocol, these documents provide a simple, working architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementation in the Internet which are network manageable are expected to adopt and implement this specification.

RFC 1066 Management Information Base for network management of TCP/IP-based internets

Authors: K. McCloghrie, M.T. Rose.

Date: August 1988

Formats: txt html json

Obsoleted by: RFC 1156

Status: UNKNOWN

DOI: 10.17487/RFC 1066

This RFC provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term. In particular, together with its companion memos which describe the structure of management information along with the initial network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets, and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.

RFC 1067 Simple Network Management Protocol

Authors: J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin.

Date: August 1988

Formats: txt html json

Obsoleted by: RFC 1098

Status: UNKNOWN

DOI: 10.17487/RFC 1067

This RFC defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.

RFC 1068 Background File Transfer Program (BFTP)

Authors: A.L. DeSchon, R.T. Braden.

Date: August 1988

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1068

This RFC describes an Internet background file transfer service that is built upon the third-party transfer model of FTP. No new protocols are involved. The purpose of this memo is to stimulate discussions on new Internet service modes.

RFC 1069 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol

Authors: R. Callon, H.W. Braun.

Date: February 1989

Formats: txt json html

Obsoletes: RFC 0986

Status: UNKNOWN

DOI: 10.17487/RFC 1069

This RFC suggests an addressing scheme for use with the ISO Connectionless Network Protocol (CLNP) in the Internet. This is a solution to one of the problems inherent in the use of "ISO-grams" in the Internet. This memo is a revision of RFC 986. This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.

RFC 1070 Use of the Internet as a subnetwork for experimentation with the OSI network layer

Authors: R.A. Hagens, N.E. Hall, M.T. Rose.

Date: February 1989

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1070

This RFC proposes a scenario for experimentation with the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) network layer protocols over the Internet and requests discussion and suggestions for improvements to this scenario. This RFC also proposes the creation of an experimental OSI internet. To participate in the experimental OSI internet, a system must abide by the agreements set forth in this RFC.

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 1072 TCP extensions for long-delay paths

Authors: V. Jacobson, R.T. Braden.

Date: October 1988

Formats: txt html json

Obsoleted by: RFC 1323, RFC 2018, RFC 6247

Status: HISTORIC

DOI: 10.17487/RFC 1072

This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance.

RFC 1073 Telnet window size option

Authors: D. Waitzman.

Date: October 1988

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1073

This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server.

RFC 1074 NSFNET backbone SPF based Interior Gateway Protocol

Authors: J. Rekhter.

Date: October 1988

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1074

This RFC is an implementation description of the standard ANSI IS-IS and ISO ES-IS routing protocols within the NSFNET backbone network.

RFC 1075 Distance Vector Multicast Routing Protocol

Authors: D. Waitzman, C. Partridge, S.E. Deering.

Date: November 1988

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1075

This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. It is derived from the Routing Information Protocol (RIP), and implements multicasting as described in RFC-1054. This is an experimental protocol, and its implementation is not recommended at this time.

RFC 1076 HEMS monitoring and control language

Authors: G. Trewitt, C. Partridge.

Date: November 1988

Formats: txt html json

Obsoletes: RFC 1023

Status: UNKNOWN

DOI: 10.17487/RFC 1076

This RFC specifies a query language for monitoring and control of network entities. This RFC supercedes RFC 1023, extending the query language and providing more discussion of the underlying issues. This language is a component of the High-Level Entity Monitoring System (HEMS) described in RFC 1021 and RFC 1022. Readers may wish to consult these RFCs when reading this memo. RFC 1024 contains detailed assignments of numbers and structures used in this system. Portions of RFC 1024 that define query language structures are superceded by definitions in this memo. This memo assumes a knowledge of the ISO data encoding standard, ASN.1.

RFC 1077 Critical issues in high bandwidth networking

Authors: B.M. Leiner.

Date: November 1988

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1077

This memo presents the results of a working group on High Bandwidth Networking. This RFC is for your information and you are encouraged to comment on the issues presented.

RFC 1078 TCP port service Multiplexer (TCPMUX)

Authors: M. Lottor.

Date: November 1988

Formats: txt json html

Obsoleted by: RFC 7805

Status: HISTORIC

DOI: 10.17487/RFC 1078

This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'.

RFC 1079 Telnet terminal speed option

Authors: C.L. Hedrick.

Date: December 1988

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1079

This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal speed information within the Telnet protocol are expected to adopt and implement this standard.

RFC 1080 Telnet remote flow control option

Authors: C.L. Hedrick.

Date: November 1988

Formats: txt json html

Obsoleted by: RFC 1372

Status: UNKNOWN

DOI: 10.17487/RFC 1080

This RFC specifies a standard for the Internet community. Hosts on the Internet that do remote flow control within the Telnet protocol are expected to adopt and implement this standard.

RFC 1081 Post Office Protocol: Version 3

Authors: M.T. Rose.

Date: November 1988

Formats: txt json html

Obsoleted by: RFC 1225

Status: UNKNOWN

DOI: 10.17487/RFC 1081

This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.

RFC 1082 Post Office Protocol: Version 3: Extended service offerings

Authors: M.T. Rose.

Date: November 1988

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1082

This memo suggests a simple method for workstations to dynamically access mail from a discussion group server, as an extension to an earlier memo which dealt with dynamically accessing mail from a mailbox server using the Post Office Protocol - Version 3 (POP3). This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. All of the extensions described in this memo to the POP3 are OPTIONAL.

RFC 1083 IAB official protocol standards

Authors: Defense Advanced Research Projects Agency, Internet Activities Board.

Date: December 1988

Formats: txt html json

Obsoleted by: RFC 1100

Status: HISTORIC

DOI: 10.17487/RFC 1083

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months.

RFC 1084 BOOTP vendor information extensions

Authors: J.K. Reynolds.

Date: December 1988

Formats: txt json html

Obsoletes: RFC 1048

Obsoleted by: RFC 1395, RFC 1497, RFC 1533

Status: UNKNOWN

DOI: 10.17487/RFC 1084

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville. This memo will be updated as additional tags are are defined. This edition introduces Tag 13 for Boot File Size. Comments and suggestions for improvements are sought.

RFC 1085 ISO presentation services on top of TCP/IP based internets

Authors: M.T. Rose.

Date: December 1988

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1085

RFC 1006 describes a mechanism for providing the ISO transport service on top of TCP/IP. Once this method is applied, one may implement "real" ISO applications on top of TCP/IP-based internets, by simply implementing OSI session, presentation, and application services on top of the transport service access point which is provided on top of the TCP. Although straight-forward, there are some environments in which the richness provided by the OSI application layer is desired, but it is nonetheless impractical to implement the underlying OSI infrastructure (i.e., the presentation, session, and transport services on top of the TCP). This memo describes an approach for providing "stream-lined" support of OSI application services on top of TCP/IP-based internets for such constrained environments. This memo proposes a standard for the Internet community.

RFC 1086 ISO-TP0 bridge between TCP and X.25

Authors: J.P. Onions, M.T. Rose.

Date: December 1988

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1086

This memo proposes a standard for the Internet community. Hosts on the Internet that choose to implement ISO TP0 transport connectivity between TCP and X.25 based hosts are expected to experiment with this proposal. TCP port 146 is reserved for this proposal.

RFC 1087 Ethics and the Internet

Authors: Defense Advanced Research Projects Agency, Internet Activities Board.

Date: January 1989

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1087

This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet.

RFC 1088 Standard for the transmission of IP datagrams over NetBIOS networks

Authors: L.J. McLaughlin.

Date: February 1989

Formats: txt json html

Also: STD 0048

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1088

This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams on NetBIOS networks.

RFC 1089 SNMP over Ethernet

Authors: M. Schoffstall, C. Davin, M. Fedor, J. Case.

Date: February 1989

Formats: txt json html

Obsoleted by: RFC 4789

Status: UNKNOWN

DOI: 10.17487/RFC 1089

This memo describes an experimental method by which the Simple Network Management Protocol (SNMP) can be used over Ethernet MAC layer framing instead of the Internet UDP/IP protocol stack. This specification is useful for LAN based network elements that support no higher layer protocols beyond the MAC sub-layer.

RFC 1090 SMTP on X.25

Authors: R. Ullmann.

Date: February 1989

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1090

This memo proposes a standard for SMTP on the virtual circuit facility provided by the X.25 standard of the CCITT.

RFC 1091 Telnet terminal-type option

Authors: J. VanBokkelen.

Date: February 1989

Formats: txt json html

Obsoletes: RFC 0930

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1091

This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC 930. A change is made to permit cycling through a list of possible terminal types and selecting the most appropriate

RFC 1092 EGP and policy based routing in the new NSFNET backbone

Authors: J. Rekhter.

Date: February 1989

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1092

This memo discusses implementation decisions for routing issues in the NSFNET, especially in the NSFNET Backbone. Of special concern is the restriction of routing information to advertize the best route as established by a policy decision.

RFC 1093 NSFNET routing architecture

Authors: H.W. Braun.

Date: February 1989

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1093

This document describes the routing architecture for the NSFNET centered around the new NSFNET Backbone, with specific emphasis on the interface between the backbone and its attached networks.

RFC 1094 NFS: Network File System Protocol specification

Authors: B. Nowicki.

Date: March 1989

Formats: txt json html

Also: RFC 1813

Status: INFORMATIONAL

DOI: 10.17487/RFC 1094

This RFC describes a protocol that Sun Microsystems, Inc., and others are using. A new version of the protocol is under development, but others may benefit from the descriptions of the current protocol, and discussion of some of the design issues.

RFC 1095 Common Management Information Services and Protocol over TCP/IP (CMOT)

Authors: U.S. Warrier, L. Besaw.

Date: April 1989

Formats: txt json html

Obsoleted by: RFC 1189

Status: UNKNOWN

DOI: 10.17487/RFC 1095

This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard. Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a comprehensive architecture and system for managing TCP/IP- based internets, and in particular the Internet.

RFC 1096 Telnet X display location option

Authors: G.A. Marcy.

Date: March 1989

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1096

This RFC specifies a standard for the Internet community. Hosts on the Internet that transmit the X display location within the Telnet protocol are expected to adopt and implement this standard.

RFC 1097 Telnet subliminal-message option

Authors: B. Miller.

Date: 1 April 1989

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1097

This RFC specifies a standard for the Internet community. Hosts on the Internet that display subliminal messages within the Telnet protocol are expected to adopt and implement this standard.

RFC 1098 Simple Network Management Protocol (SNMP)

Authors: J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin.

Date: April 1989

Formats: txt json html

Obsoletes: RFC 1067

Obsoleted by: RFC 1157

Status: UNKNOWN

DOI: 10.17487/RFC 1098

This RFC is a re-release of RFC 1067, with a changed "Status of this Memo" section. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet.

RFC 1099 Request for Comments Summary: RFC Numbers 1000-1099

Authors: J. Reynolds.

Date: December 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1099

RFC 1100 IAB official protocol standards

Authors: Defense Advanced Research Projects Agency, Internet Activities Board.

Date: April 1989

Formats: txt json html

Obsoletes: RFC 1083

Obsoleted by: RFC 1130

Status: HISTORIC

DOI: 10.17487/RFC 1100

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority (see the contact information at the end of this memo). Do not use this memo after 31-July-89.

RFC 1101 DNS encoding of network names and other types

Authors: P. Mockapetris.

Date: April 1989

Formats: txt json html

Updates: RFC 1034, RFC 1035

Status: UNKNOWN

DOI: 10.17487/RFC 1101

This RFC proposes two extensions to the Domain Name System: - A specific method for entering and retrieving RRs which map between network names and numbers. - Ideas for a general method for describing mappings between arbitrary identifiers and numbers. The method for mapping between network names and addresses is a proposed standard, the ideas for a general method are experimental.

RFC 1102 Policy routing in Internet protocols

Authors: D.D. Clark.

Date: May 1989

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1102

The purpose of this RFC is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet.

RFC 1103 Proposed standard for the transmission of IP datagrams over FDDI Networks

Authors: D. Katz.

Date: June 1989

Formats: txt html json

Obsoleted by: RFC 1188

Status: UNKNOWN

DOI: 10.17487/RFC 1103

This RFC specifies a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]

RFC 1104 Models of policy based routing

Authors: H.W. Braun.

Date: June 1989

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1104

The purpose of this RFC is to outline a variety of models for policy based routing. The relative benefits of the different approaches are reviewed. Discussions and comments are explicitly encouraged to move toward the best policy based routing model that scales well within a large internetworking environment.

RFC 1105 Border Gateway Protocol (BGP)

Authors: K. Lougheed, Y. Rekhter.

Date: June 1989

Formats: txt json html

Obsoleted by: RFC 1163

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1105

This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK]

RFC 1106 TCP big window and NAK options

Authors: R. Fox.

Date: June 1989

Formats: txt html json

Obsoleted by: RFC 6247

Status: HISTORIC

DOI: 10.17487/RFC 1106

Two extensions to the TCP protocol are described in this RFC in order to provide a more efficient operation over a network with a high bandwidth*delay product. The main issue that still needs to be solved is congestion versus noise. This issue is touched on in this memo, but further research is still needed on the applicability of the extensions in the Internet as a whole infrastructure and not just high bandwidth*delay product networks. Even with this outstanding issue, this document does describe the use of these options in the isolated satellite network environment to help facilitate more efficient use of this special medium to help off load bulk data transfers from links needed for interactive use.

RFC 1107 Plan for Internet directory services

Authors: K.R. Sollins.

Date: July 1989

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1107

This memo proposes a program to develop a directory service for the Internet. It reports the results of a meeting held in February 1989, which was convened to review requirements and options for such a service. This proposal is offered for comment, and does not represent a committed research activity of the Internet community.

RFC 1108 U.S

Authors: Department of Defense Security Options for the Internet Protocol. S. Kent.

Date: November 1991

Formats: txt json html

Obsoletes: RFC 1038

Status: HISTORIC

DOI: 10.17487/RFC 1108

This RFC specifies the U.S. Department of Defense Basic SecurityOption and the top-level description of the Extended Security Option for use with the Internet Protocol. This RFC obsoletes RFC 1038"Revised IP Security Option", dated January 1988.

RFC 1109 Report of the second Ad Hoc Network Management Review Group

Authors: V.G. Cerf.

Date: August 1989

Formats: txt json html

Status: UNKNOWN

DOI: 10.17487/RFC 1109

This RFC reports an official Internet Activities Board (IAB) policy position on the treatment of Network Management in the Internet. This RFC presents the results and recommendations of the second Ad Hoc Network Management Review on June 12, 1989. The results of the first such meeting were reported in RFC 1052.

RFC 1110 Problem with the TCP big window option

Authors: A.M. McKenzie.

Date: August 1989

Formats: txt json html

Obsoleted by: RFC 6247

Status: HISTORIC

DOI: 10.17487/RFC 1110

The TCP Big Window option discussed in RFC 1106 will not work properly in an Internet environment which has both a high bandwidth * delay product and the possibility of disordering and duplicating packets. In such networks, the window size must not be increased without a similar increase in the sequence number space. Therefore, a different approach to big windows should be taken in the Internet.

RFC 1111 Request for comments on Request for Comments: Instructions to RFC authors

Authors: J. Postel.

Date: August 1989

Formats: txt json html

Obsoletes: RFC 0825

Obsoleted by: RFC 1543, RFC 2223

Status: INFORMATIONAL

DOI: 10.17487/RFC 1111

This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard.

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 1113 Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures

Authors: J. Linn.

Date: August 1989

Formats: txt html json

Obsoletes: RFC 0989, RFC 1040

Obsoleted by: RFC 1421

Status: HISTORIC

DOI: 10.17487/RFC 1113

This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK]

RFC 1114 Privacy enhancement for Internet electronic mail: Part II - certificate-based key management

Authors: S.T. Kent, J. Linn.

Date: August 1989

Formats: txt json html

Obsoleted by: RFC 1422

Status: HISTORIC

DOI: 10.17487/RFC 1114

This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK]

RFC 1115 Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers

Authors: J. Linn.

Date: August 1989

Formats: txt json html

Obsoleted by: RFC 1423

Status: HISTORIC

DOI: 10.17487/RFC 1115

This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK]

RFC 1116 Telnet Linemode option

Authors: D.A. Borman.

Date: August 1989

Formats: txt html json

Obsoleted by: RFC 1184

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1116

Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK]

RFC 1117 Internet numbers

Authors: S. Romano, M.K. Stahl, M. Recker.

Date: August 1989

Formats: txt html json

Obsoletes: RFC 1062, RFC 1020, RFC 0997

Obsoleted by: RFC 1166

Status: INFORMATIONAL

DOI: 10.17487/RFC 1117

This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community.

RFC 1118 Hitchhikers guide to the Internet

Authors: E. Krol.

Date: September 1989

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1118

This RFC is being distributed to members of the Internet community in order to make available some "hints" which will allow new network participants to understand how the direction of the Internet is set, how to acquire online information and how to be a good Internet neighbor. While the information discussed may not be relevant to the research problems of the Internet, it may be interesting to a number of researchers and implementors. No standards are defined or specified in this memo.

RFC 1119 Network Time Protocol (version 2) specification and implementation

Authors: D.L. Mills.

Date: September 1989

Formats: txt ps json pdf html

Obsoletes: RFC 0958, RFC 1059

Obsoleted by: RFC 1305

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1119

This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. [STANDARDS-TRACK]

RFC 1120 Internet Activities Board

Authors: V. Cerf.

Date: September 1989

Formats: txt json html

Obsoleted by: RFC 1160

Status: INFORMATIONAL

DOI: 10.17487/RFC 1120

This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard.

RFC 1121 Act one - the poems

Authors: J. Postel, L. Kleinrock, V.G. Cerf, B. Boehm.

Date: September 1989

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1121

This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET.

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 1124 Policy issues in interconnecting networks

Authors: B.M. Leiner.

Date: September 1989

Formats: txt ps pdf json html

Status: UNKNOWN

DOI: 10.17487/RFC 1124

To support the activities of the Federal Research Internet Coordinating Committee (FRICC) in creating an interconnected set of networks to serve the research community, two workshops were held to address the technical support of policy issues that arise when interconnecting such networks. Held under the suspices of the Internet Activities Board at the request of the FRICC, and sponsored by NASA through RIACS, the workshops addressed the required and feasible technologies and architectures that could be used to satisfy the desired policies for interconnection. The purpose of this RFC is to report the results of these workshops.

RFC 1125 Policy requirements for inter Administrative Domain routing

Authors: D. Estrin.

Date: November 1989

Formats: txt json ps pdf html

Status: UNKNOWN

DOI: 10.17487/RFC 1125

The purpose of this memo is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the development and adoption of standards.

RFC 1126 Goals and functional requirements for inter-autonomous system routing

Authors: M. Little.

Date: October 1989

Formats: txt html json

Status: UNKNOWN

DOI: 10.17487/RFC 1126

This document describes the functional requirements for a routing protocol to be used between autonomous systems. This document is intended as a necessary precursor to the design of a new inter- autonomous system routing protocol and specifies requirements for the Internet applicable for use with the current DoD IP, the ISO IP, and future Internet Protocols. It is intended that these requirements will form the basis for the future development of a new inter-autonomous systems routing architecture and protocol. This memo does not specify a standard.

RFC 1127 Perspective on the Host Requirements RFCs

Authors: R.T. Braden.

Date: October 1989

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1127

This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol.

RFC 1128 Measured performance of the Network Time Protocol in the Internet system

Authors: D.L. Mills.

Date: October 1989

Formats: txt json pdf html ps

Status: UNKNOWN

DOI: 10.17487/RFC 1128

This paper describes a series of experiments involving over 100,000 hosts of the Internet system and located in the U.S., Europe and the Pacific. The experiments are designed to evaluate the availability, accuracy and reliability of international standard time distribution using the DARPA/NSF Internet and the Network Time Protocol (NTP), which is specified in RFC-1119. NTP is designed specifically for use in a large, diverse internet system operating at speeds from mundane to lightwave. In NTP a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration exchange precision timestamps in order to synchronize subnet clocks to each other and national time standards via wire or radio. The experiments are designed to locate Internet hosts and gateways that provide time by one of three time distribution protocols and evaluate the accuracy of their indications. For those hosts that support NTP, the experiments determine the distribution of errors and other statistics over paths spanning major portions of the globe. Finally, the experiments evaluate the accuracy and reliability of precision timekeeping using NTP and typical Internet paths involving DARPA, NSFNET and other agency networks. The experiments demonstrate that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo does not specify a standard.

RFC 1129 Internet Time Synchronization: The Network Time Protocol

Authors: D.L. Mills.

Date: October 1989

Formats: txt json ps html pdf

Also: RFC 1119

Status: INFORMATIONAL

DOI: 10.17487/RFC 1129

This memo describes the Network Time Protocol (NTP) designed to distribute time information in a large, diverse internet system operating at speeds from mundane to lightwave. It uses a returnable- time architecture in which a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute time information within a network via local routing algorithms and time daemons. The architectures, algorithms and protocols which have evolved to NTP over several years of implementation and refinement are described in this paper. The synchronization subnet which has been in regular operation in the Internet for the last several years is described along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo describes the Network Time Protocol in RFC-1119.

RFC 1130 IAB official protocol standards

Authors: Defense Advanced Research Projects Agency, Internet Activities Board.

Date: October 1989

Formats: txt json html

Obsoletes: RFC 1100

Obsoleted by: RFC 1140

Status: HISTORIC

DOI: 10.17487/RFC 1130

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).

RFC 1131 OSPF specification

Authors: J. Moy.

Date: October 1989

Formats: txt json ps html pdf

Obsoleted by: RFC 1247

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1131

This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK]

RFC 1132 Standard for the transmission of 802.2 packets over IPX networks

Authors: L.J. McLaughlin.

Date: November 1989

Formats: txt html json

Also: STD 0049

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1132

This document specifies a standard method of encapsulating 802.2 packets on networks supporting Novell's Internet Packet Exchange Protocol (IPX). It obsoletes earlier documents detailing the transmission of Internet packets over IPX networks. It differs from these earlier documents in that it allows for the transmission of multiple network protocols over IPX and for the transmission of packets through IPX bridges.

RFC 1133 Routing between the NSFNET and the DDN

Authors: J.Y. Yu, H.W. Braun.

Date: November 1989

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1133

This document is a case study of the implementation of routing between the NSFNET and the DDN components (the MILNET and the ARPANET). We hope that it can be used to expand towards interconnection of other Administrative Domains. We would welcome discussion and suggestions about the methods employed for the interconnections. No standards are specified in this memo.

RFC 1134 Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links

Authors: D. Perkins.

Date: November 1989

Formats: txt json html

Obsoleted by: RFC 1171

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1134

The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts:
1. A method for encapsulating datagrams over serial links.
2. An extensible Link Control Protocol (LCP).
3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
This document defines the encapsulation scheme, the basic LCP, and anNCP for establishing and configuring the Internet Protocol (IP)(called the IP Control Protocol, IPCP).
The options and facilities used by the LCP and the IPCP are defined in separate documents. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET,OSI) are expected to be developed as needed.

RFC 1135 Helminthiasis of the Internet

Authors: J.K. Reynolds.

Date: December 1989

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1135

This memo takes a look back at the helminthiasis (infestation with, or disease caused by parasitic worms) of the Internet that was unleashed the evening of 2 November 1988. This RFC provides information about an event that occurred in the life of the Internet. This memo does not specify any standard. This document provides a glimpse at the infection, its festering, and cure. The impact of the worm on the Internet community, ethics statements, the role of the news media, crime in the computer world, and future prevention is discussed. A documentation review presents four publications that describe in detail this particular parasitic computer program. Reference and bibliography sections are also included.

RFC 1136 Administrative Domains and Routing Domains: A model for routing in the Internet

Authors: S. Hares, D. Katz.

Date: December 1989

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1136

This RFC proposes a model for describing routing within the Internet. The model is an adaptation of the "OSI Routeing Framework". This memo does not specify an Internet standard.

RFC 1137 Mapping between full RFC 822 and RFC 822 with restricted encoding

Authors: S. Kille.

Date: December 1989

Formats: txt html json

Updates: RFC 0976

Status: HISTORIC

DOI: 10.17487/RFC 1137

This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard.

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 1139 Echo function for ISO 8473

Authors: R.A. Hagens.

Date: January 1990

Formats: txt json html

Obsoleted by: RFC 1574, RFC 1575

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1139

This memo defines an echo function for the connection-less network layer protocol. Two mechanisms are introduced that may be used to implement the echo function. The first mechanism is recommended as an interim solution for the Internet community. The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item.
When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard.

RFC 1140 IAB official protocol standards

Authors: Defense Advanced Research Projects Agency, Internet Activities Board.

Date: May 1990

Formats: txt html json

Obsoletes: RFC 1130

Obsoleted by: RFC 1200

Status: HISTORIC

DOI: 10.17487/RFC 1140

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority. Do not use this edition after 31-Aug-90.

RFC 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 1142 OSI IS-IS Intra-domain Routing Protocol

Authors: D. Oran, Ed..

Date: February 1990

Formats: txt ps json html pdf

Obsoleted by: RFC 7142

Status: HISTORIC

DOI: 10.17487/RFC 1142

This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard.

RFC 1143 The Q Method of Implementing TELNET Option Negotiation

Authors: D.J. Bernstein.

Date: February 1990

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1143

This is RFC discusses an implementation approach to option negotiation in the Telnet protocol (RFC 854). It does not propose any changes to the TELNET protocol. Rather, it discusses the implementation of the protocol of one feature, only. This is not a protocol specification. This is an experimental method of implementing a protocol.

RFC 1144 Compressing TCP/IP Headers for Low-Speed Serial Links

Authors: V. Jacobson.

Date: February 1990

Formats: txt html ps json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1144

This RFC describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links. The motivation, implementation and performance of the method are described. C code for a sample implementation is given for reference. [STANDARDS- TRACK]

RFC 1145 TCP alternate checksum options

Authors: J. Zweig, C. Partridge.

Date: February 1990

Formats: txt html json

Obsoleted by: RFC 1146, RFC 6247

Status: HISTORIC

DOI: 10.17487/RFC 1145

This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use.

RFC 1146 TCP alternate checksum options

Authors: J. Zweig, C. Partridge.

Date: March 1990

Formats: txt json html

Obsoletes: RFC 1145

Obsoleted by: RFC 6247

Status: HISTORIC

DOI: 10.17487/RFC 1146

This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. Note: This RFC corrects errors introduced in the editing process in RFC 1145.

RFC 1147 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices

Authors: R.H. Stine.

Date: April 1990

Formats: txt pdf json ps html

Obsoleted by: RFC 1470

Status: INFORMATIONAL

DOI: 10.17487/RFC 1147

The goal of this FYI memo is to provide practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. Entries in the catalog tell what a tool does, how it works, and how it can be obtained.

RFC 1148 Mapping between X.400(1988) / ISO 10021 and RFC 822

Authors: S.E. Kille.

Date: March 1990

Formats: txt html json

Obsoleted by: RFC 2156, RFC 1327

Updates: RFC 1026, RFC 0987, RFC 1138, RFC 0822

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1148

This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing.

RFC 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 1150 FYI on FYI: Introduction to the FYI Notes

Authors: G.S. Malkin, J.K. Reynolds.

Date: March 1990

Formats: txt html json

Obsoleted by: RFC 6360

Status: HISTORIC

DOI: 10.17487/RFC 1150

This memo is the first in a new sub-series of RFCs called FYIs (For Your Information). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 1.]

RFC 1151 Version 2 of the Reliable Data Protocol (RDP)

Authors: C. Partridge, R.M. Hinden.

Date: April 1990

Formats: txt html json

Updates: RFC 0908

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1151

This RFC suggests several updates to the specification of the Reliable Data Protocol (RDP) in RFC-908 based on experience with the protocol. This revised version of the protocol is experimental.

RFC 1152 Workshop report: Internet research steering group workshop on very-high-speed networks

Authors: C. Partridge.

Date: April 1990

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1152

This memo is a report on a workshop sponsored by the Internet Research Steering Group. This memo is for information only. This RFC does not specify an Internet standard.

RFC 1153 Digest message format

Authors: F.J. Wancho.

Date: April 1990

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1153

This memo describes the de facto standard Digest Message Format. This is an elective experimental protocol.

RFC 1154 Encoding header field for internet messages

Authors: D. Robinson, R. Ullmann.

Date: April 1990

Formats: txt html json

Obsoleted by: RFC 1505

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1154

This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement).

RFC 1155 Structure and identification of management information for TCP/IP-based internets

Authors: M.T. Rose, K. McCloghrie.

Date: May 1990

Formats: txt html json

Obsoletes: RFC 1065

Also: STD 0016

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1155

This RFC is a re-release of RFC 1065, with a changed "Status of this Memo", plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1065. [STANDARDS-TRACK]

RFC 1156 Management Information Base for network management of TCP/IP-based internets

Authors: K. McCloghrie, M.T. Rose.

Date: May 1990

Formats: txt json html

Obsoletes: RFC 1066

Status: HISTORIC

DOI: 10.17487/RFC 1156

This RFC is a re-release of RFC 1066, with a changed "Status of this Memo", "IAB Policy Statement", and "Introduction" sections plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1066. [STANDARDS-TRACK]

RFC 1157 Simple Network Management Protocol (SNMP)

Authors: J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin.

Date: May 1990

Formats: txt json html

Obsoletes: RFC 1098

Status: HISTORIC

DOI: 10.17487/RFC 1157

This RFC is a re-release of RFC 1098, with a changed "Status of this Memo" section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK]

RFC 1158 Management Information Base for network management of TCP/IP-based internets: MIB-II

Authors: M.T. Rose.

Date: May 1990

Formats: txt html json

Obsoleted by: RFC 1213

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1158

This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK]

RFC 1159 Message Send Protocol

Authors: R. Nelson.

Date: June 1990

Formats: txt html json

Obsoleted by: RFC 1312

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1159

This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol.

RFC 1160 Internet Activities Board

Authors: V. Cerf.

Date: May 1990

Formats: txt html json

Obsoletes: RFC 1120

Status: INFORMATIONAL

DOI: 10.17487/RFC 1160

This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. This is a revision of RFC 1120.

RFC 1161 SNMP over OSI

Authors: M.T. Rose.

Date: June 1990

Formats: txt html json

Obsoleted by: RFC 1418

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1161

This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community,

RFC 1162 Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base

Authors: G. Satz.

Date: June 1990

Formats: txt json html

Obsoleted by: RFC 1238

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1162

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community.

RFC 1163 Border Gateway Protocol (BGP)

Authors: K. Lougheed, Y. Rekhter.

Date: June 1990

Formats: txt json html

Obsoletes: RFC 1105

Obsoleted by: RFC 1267

Status: HISTORIC

DOI: 10.17487/RFC 1163

This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC 1164 Application of the Border Gateway Protocol in the Internet

Authors: J.C. Honig, D. Katz, M. Mathis, Y. Rekhter, J.Y. Yu.

Date: June 1990

Formats: txt html json

Obsoleted by: RFC 1268

Status: HISTORIC

DOI: 10.17487/RFC 1164

This RFC, together with its companion RFC-1163, "A Border Gateway Protocol (BGP)", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC 1165 Network Time Protocol (NTP) over the OSI Remote Operations Service

Authors: J. Crowcroft, J.P. Onions.

Date: June 1990

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1165

This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism.

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 1167 Thoughts on the National Research and Education Network

Authors: V.G. Cerf.

Date: July 1990

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1167

The memo provides a brief outline of a National Research and Education Network (NREN). This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations.

RFC 1168 Intermail and Commercial Mail Relay services

Authors: A. Westine, A.L. DeSchon, J. Postel, C.E. Ward.

Date: July 1990

Formats: txt html ps pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1168

This RFC discusses the history and evolution of the Intermail and Commercial mail systems. The problems encountered in operating a store-and-forward mail relay between commercial systems such as Telemail, MCI Mail and Dialcom are also discussed. This RFC provides information for the Internet community, and does not specify any standard.

RFC 1169 Explaining the role of GOSIP

Authors: V.G. Cerf, K.L. Mills.

Date: August 1990

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1169

This informational RFC represents the official view of the Internet Activities Board (IAB), after coordination with the Federal Networking Council (FNC). This RFC does not specify a standard.

RFC 1170 Public key standards and licenses

Authors: R.B. Fougner.

Date: January 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1170

This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses. This memo is for informational use only, and does not constitute an Internet standard.

RFC 1171 Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links

Authors: D. Perkins.

Date: July 1990

Formats: txt html json

Obsoletes: RFC 1134

Obsoleted by: RFC 1331

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1171

The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts:
1. A method for encapsulating datagrams over serial links.
2. An extensible Link Control Protocol (LCP).
3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
This document defines the encapsulation scheme, the basic LCP, and anNCP for establishing and configuring the Internet Protocol (IP)(called the IP Control Protocol, IPCP).
The options and facilities used by the LCP and the IPCP are defined in separate documents. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET,OSI) are expected to be developed as needed.

RFC 1172 Point-to-Point Protocol (PPP) initial configuration options

Authors: D. Perkins, R. Hobby.

Date: July 1990

Formats: txt json html

Obsoleted by: RFC 1331, RFC 1332

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1172

The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of
1) a method for encapsulating datagrams over serial links,2) an extensible Link Control Protocol (LCP), and3) a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called theIP Control Protocol, IPCP) are defined in The Point-to-Point Protocol(PPP) [1].
This document defines the intial options used by the LCP and IPCP. It also defines a method of Link Quality Monitoring and a simple authentication scheme.

RFC 1173 Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet

Authors: J. VanBokkelen.

Date: August 1990

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1173

This informational RFC describes the conventions to be followed by those in charge of networks and hosts in the Internet. It is a summary of the "oral tradition" of the Internet on this subject. [RFC Editor's note: This memo is a contribution by the author of his view of these conventions. It is expected that this RFC will provide a basis for the development of official policies in the future.] These conventions may be supplemented or amended by the policies of specific local and regional components of the Internet. This RFC does not specify a standard, or a policy of the IAB.

RFC 1174 IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status

Authors: V.G. Cerf.

Date: August 1990

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1174

This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement. This RFC does not specify a standard.

RFC 1175 FYI on where to start: A bibliography of internetworking information

Authors: K.L. Bowers, T.L. LaQuey, J.K. Reynolds, K. Roubicek, M.K. Stahl, A. Yuan.

Date: August 1990

Formats: txt html json

Also: FYI 0003

Status: INFORMATIONAL

DOI: 10.17487/RFC 1175

The intent of this bibliography is to offer a representative collection of resources of information that will help the reader become familiar with the concepts of internetworking. It is meant to be a starting place for further research. There are references to other sources of information for those users wishing to pursue, in greater depth, the issues and complexities of the current networking environment.

RFC 1176 Interactive Mail Access Protocol: Version 2

Authors: M.R. Crispin.

Date: August 1990

Formats: txt json html

Obsoletes: RFC 1064

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1176

This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server ("repository"). It obosoletes RFC 1064. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

RFC 1177 FYI on Questions and Answers: Answers to commonly asked "new internet user" questions

Authors: G.S. Malkin, A.N. Marine, J.K. Reynolds.

Date: August 1990

Formats: txt json html

Obsoleted by: RFC 1206

Status: INFORMATIONAL

DOI: 10.17487/RFC 1177

This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.]

RFC 1178 Choosing a name for your computer

Authors: D. Libes.

Date: August 1990

Formats: txt html json

Also: FYI 0005

Status: INFORMATIONAL

DOI: 10.17487/RFC 1178

In order to easily distinguish between multiple computers, we give them names. Experience has taught us that it is as easy to choose bad names as it is to choose good ones. This essay presents guidelines for deciding what makes a name good or bad.
Keywords: domain name system, naming conventions, computer administration, computer network management

RFC 1179 Line printer daemon protocol

Authors: L. McLaughlin.

Date: August 1990

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1179

This RFC describes an existing print server protocol widely used on the Internet for communicating between line printer daemons (both clients and servers). This memo is for informational purposes only, and does not specify an Internet standard. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

RFC 1180 TCP/IP tutorial

Authors: T.J. Socolofsky, C.J. Kale.

Date: January 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1180

This RFC is a tutorial on the TCP-IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard.

RFC 1181 RIPE Terms of Reference

Authors: R. Blokzijl.

Date: September 1990

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1181

This RFC describes the Terms of Reference of RIPE (Reseaux IP Europeens), the cooperation of European IP networks. This memo provides information for the Internet community. It does not specify any standard.

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 1184 Telnet Linemode Option

Authors: D.A. Borman.

Date: October 1990

Formats: txt html json

Obsoletes: RFC 1116

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1184

This RFC specifies a procedure for line at a time terminal interaction based on the Telnet Protocol. It obsoletes RFC 1116. [STANDARDS-TRACK]

RFC 1185 TCP Extension for High-Speed Paths

Authors: V. Jacobson, R.T. Braden, L. Zhang.

Date: October 1990

Formats: txt html json

Obsoleted by: RFC 1323

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1185

This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

RFC 1186 MD4 Message Digest Algorithm

Authors: R.L. Rivest.

Date: October 1990

Formats: txt json html

Obsoleted by: RFC 1320

Status: INFORMATIONAL

DOI: 10.17487/RFC 1186

This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard.

RFC 1187 Bulk Table Retrieval with the SNMP

Authors: M.T. Rose, K. McCloghrie, J.R. Davin.

Date: October 1990

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1187

This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP). This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify a standard for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

RFC 1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks

Authors: D. Katz.

Date: October 1990

Formats: txt html json

Obsoletes: RFC 1103

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1188

This document specifies a method for the use of IP and ARP on FDDI networks. The encapsulation method used is described, as well as various media-specific issues.

RFC 1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP)

Authors: U.S. Warrier, L. Besaw, L. LaBarre, B.D. Handspicker.

Date: October 1990

Formats: txt html json

Obsoletes: RFC 1095

Status: HISTORIC

DOI: 10.17487/RFC 1189

This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in the Internet. [STANDARDS-TRACK]

RFC 1190 Experimental Internet Stream Protocol: Version 2 (ST-II)

Authors: C. Topolcic.

Date: October 1990

Formats: txt html json

Obsoletes: IEN119

Obsoleted by: RFC 1819

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1190

This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

RFC 1191 Path MTU discovery

Authors: J. Mogul, S. Deering.

Date: November 1990

Formats: txt html json

Obsoletes: RFC 1063

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1191

This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice.

RFC 1192 Commercialization of the Internet summary report

Authors: B. Kahin.

Date: November 1990

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1192

This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F. Kennedy School of Government, Harvard University, March 1-3, 1990. This memo provides information for the Internet community. It does not specify any standard.

RFC 1193 Client requirements for real-time communication services

Authors: D. Ferrari.

Date: November 1990

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1193

A real-time communication service provides its clients with the ability to specify their performance requirements and to obtain guarantees about the satisfaction of those requirements. In this paper, we propose a set of performance specifications that seem appropriate for such services; they include various types of delay bounds, throughput bounds, and reliability bounds. We also describe other requirements and desirable properties from a client's viewpoint, and the ways in which each requirement is to be translated to make it suitable for lower levels in the protocol hierarchy.Finally, we present some examples of requirements specification, and discuss some of the possible objections to our approach.
This research has been supported in part by AT&T Bell Laboratories, the University of California under a MICRO grant, and theInternational Computer Science Institute. The views and conclusions in this document are those of the author and should not be interpreted as representing official policies, either expressed or implied, of any of the sponsoring organizations.

RFC 1194 Finger User Information Protocol

Authors: D.P. Zimmerman.

Date: November 1990

Formats: txt html json

Obsoletes: RFC 0742

Obsoleted by: RFC 1196, RFC 1288

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1194

This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program.
Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition.

RFC 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 1196 Finger User Information Protocol

Authors: D.P. Zimmerman.

Date: December 1990

Formats: txt json html

Obsoletes: RFC 1194, RFC 0742

Obsoleted by: RFC 1288

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1196

This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program.
Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194.

RFC 1197 Using ODA for translating multimedia information

Authors: M. Sherman.

Date: December 1990

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1197

The purpose of this RFC is to inform implementors of multimedia systems about our experiences using ISO 8613: Office Document Architecture (ODA). Because ODA is being proposed as an encoding format for use in multimedia mail and file exchange, implementors wishing to use ODA in an open systems environment may profit from our experiences. This memo provides information for the Internet community. It does not specify any standard.

RFC 1198 FYI on the X window system

Authors: R.W. Scheifler.

Date: January 1991

Formats: txt html json

Also: FYI 0006

Status: INFORMATIONAL

DOI: 10.17487/RFC 1198

This FYI RFC provides pointers to the published standards of the MIT X Consortium. This memo provides information for the Internet community. It does not specify any Internet standard.

RFC 1199 Request for Comments Summary Notes: 1100-1199

Authors: J. Reynolds.

Date: December 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1199

RFC 1200 IAB official protocol standards

Authors: Defense Advanced Research Projects Agency, Internet Activities Board.

Date: April 1991

Formats: txt html json

Obsoletes: RFC 1140

Obsoleted by: RFC 1250

Status: HISTORIC

DOI: 10.17487/RFC 1200

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information.

RFC 1201 Transmitting IP traffic over ARCNET networks

Authors: D. Provan.

Date: February 1991

Formats: txt html json

Obsoletes: RFC 1051

Also: STD 0046

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1201

This memo defines a protocol for the transmission of IP and ARP packets over the ARCnet Local Area Network.This memo specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across ARCNET using the "ARCNET Packet Header Definition Standard". [STANDARDS-TRACK]

RFC 1202 Directory Assistance service

Authors: M.T. Rose.

Date: February 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1202

This document defines a mechanism by which a user-interface may access a textual DAP-like interface over a TCP/IP connection. This is a local mechanism. This memo provides information for the Internet community. It does not specify any standard.

RFC 1203 Interactive Mail Access Protocol: Version 3

Authors: J. Rice.

Date: February 1991

Formats: txt json html

Obsoletes: RFC 1064

Status: HISTORIC

DOI: 10.17487/RFC 1203

This RFC suggests a method for workstations to access mail dynamically from a mailbox server ("repository"). The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.

RFC 1204 Message Posting Protocol (MPP)

Authors: S. Yeh, D. Lee.

Date: February 1991

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1204

This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.

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 1206 FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions

Authors: G.S. Malkin, A.N. Marine.

Date: February 1991

Formats: txt json html

Obsoletes: RFC 1177

Obsoleted by: RFC 1325

Status: INFORMATIONAL

DOI: 10.17487/RFC 1206

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4]

RFC 1207 FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions

Authors: G.S. Malkin, A.N. Marine, J.K. Reynolds.

Date: February 1991

Formats: txt json html

Also: FYI 0007

Status: INFORMATIONAL

DOI: 10.17487/RFC 1207

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard.

RFC 1208 A Glossary of Networking Terms

Authors: O.J. Jacobsen, D.C. Lynch.

Date: March 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1208

This RFC is a glossary adapted from "The INTEROP Pocket Glossary of Networking Terms" distributed at Interop '90. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1209 The Transmission of IP Datagrams over the SMDS Service

Authors: D. Piscitello, J. Lawrence.

Date: March 1991

Formats: txt html json

Also: STD 0052

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1209

This memo describes an initial use of IP and ARP in an SMDS service environment configured as a logical IP subnetwork, LIS (described below). The encapsulation method used is described, as well as various service-specific issues. This memo does not preclude subsequent treatment of the SMDS Service in configurations other thanLIS; specifically, public or inter-company, inter-enterprise configurations may be treated differently and will be described in future documents. This document considers only directly connected IP end-stations or routers; issues raised by MAC level bridging are beyond the scope of this paper.

RFC 1210 Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990

Authors: V.G. Cerf, P.T. Kirstein, B. Randell.

Date: March 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1210

This report summarises user requirements for networking and related infrastructure facilities needed to enable effective cooperation between US and European research teams participating in the plannedESPRIT-DARPA/NSF programme of collaborative research in InformationScience and Technology. It analyses the problems and disparities of the current facilities, and suggests appropriate one and three year targets for improvements. It proposes a number of initial actions aimed at achieving these targets. Finally, the workshop has identified a non-exhaustive set of important issues upon which support of future research will depend. These issues could be studied in the short term, with the aim of initiating a programme of joint research in collaboration technology within the next year.

RFC 1211 Problems with the maintenance of large mailing lists

Authors: A. Westine, J. Postel.

Date: March 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1211

This RFC discusses problems with maintaining large mailing lists, especially the processing of error reports. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1212 Concise MIB definitions

Authors: M.T. Rose, K. McCloghrie.

Date: March 1991

Formats: txt json html

Also: STD 0016

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1212

This memo describes a straight-forward approach toward producing concise, yet descriptive, MIB modules. This memo defines a format for producing MIB modules. [STANDARDS-TRACK]

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 1214 OSI internet management: Management Information Base

Authors: L. LaBarre.

Date: April 1991

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1214

This RFC documents a MIB for use with CMIP, either over pure OSI stacks or with the CMIP over TCP specification. It redefines objects comprised by the second revision of the Management Information Base for Network Management of TCP/IP-based internets: MIB-II so as to conform to the OSI structure of management information. This document is a product of the IETF OIM working group.

RFC 1215 Convention for defining traps for use with the SNMP

Authors: M.T. Rose.

Date: March 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1215

This memo suggests a straight-forward approach towards defining traps used with the SNMP. This memo provides information for the Internet community. It does not specify any standard.

RFC 1216 Gigabit network economics and paradigm shifts

Authors: P. Richard, P. Kynikos.

Date: 1 April 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1216

This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]

RFC 1217 Memo from the Consortium for Slow Commotion Research (CSCR)

Authors: V.G. Cerf.

Date: 1 April 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1217

This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1218 Naming scheme for c=US

Authors: North American Directory Forum.

Date: April 1991

Formats: txt html json

Obsoleted by: RFC 1255, RFC 1417

Status: INFORMATIONAL

DOI: 10.17487/RFC 1218

This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1219 On the assignment of subnet numbers

Authors: P.F. Tsuchiya.

Date: April 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1219

This memo suggests a new procedure for assigning subnet numbers. Use of this assignment technique within a network would be a purely local matter, and would not effect other networks. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1220 Point-to-Point Protocol extensions for bridging

Authors: F. Baker.

Date: April 1991

Formats: txt html json

Obsoleted by: RFC 1638

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1220

This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK]

RFC 1221 Host Access Protocol (HAP) specification: Version 2

Authors: W. Edmond.

Date: April 1991

Formats: txt html json

Updates: RFC 0907

Status: INFORMATIONAL

DOI: 10.17487/RFC 1221

This memo describes the Host Access Protocol implemented in the Terrestrial Wideband Network (TWBNET). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1222 Advancing the NSFNET routing architecture

Authors: H.W. Braun, Y. Rekhter.

Date: May 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1222

This RFC suggests improvements in the NSFNET routing architecture to accommodate a more flexible interface to the Backbone clients. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel

Authors: J.M. Halpern.

Date: May 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1223

The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1224 Techniques for managing asynchronously generated alerts

Authors: L. Steinberg.

Date: May 1991

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1224

This RFC explores mechanisms to prevent a remotely managed entity from burdening a manager or network with an unexpected amount of network management information, and to ensure delivery of "important" information. The focus is on controlling the flow of asynchronously generated information, and not how the information is generated.

RFC 1225 Post Office Protocol: Version 3

Authors: M.T. Rose.

Date: May 1991

Formats: txt html json

Obsoletes: RFC 1081

Obsoleted by: RFC 1460

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1225

This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK]

RFC 1226 Internet protocol encapsulation of AX.25 frames

Authors: B. Kantor.

Date: May 1991

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1226

This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets. This technique is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC 1227 SNMP MUX protocol and MIB

Authors: M.T. Rose.

Date: May 1991

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1227

This memo suggests a mechanism by which a user process may associate itself with the local SNMP agent on a host, in order to implement portions of the MIB. This mechanism would be local to the host.This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC 1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface

Authors: G. Carpenter, B. Wijnen.

Date: May 1991

Formats: txt html json

Obsoleted by: RFC 1592

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1228

This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC 1229 Extensions to the generic-interface MIB

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 1234 Tunneling IPX traffic through IP networks

Authors: D. Provan.

Date: June 1991

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1234

This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. [STANDARDS-TRACK] This memo defines objects for managing DS1 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]

RFC 1235 Coherent File Distribution Protocol

Authors: J. Ioannidis, G. Maguire.

Date: June 1991

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1235

This memo describes the Coherent File Distribution Protocol (CFDP). This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC 1236 IP to X.121 address mapping for DDN

Authors: L. Morales, P. Hasse.

Date: June 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1236

This memo defines a standard way of converting IP addresses to CCITT X.121 addresses and is the recommended standard for use on the Internet, specifically for the Defense Data Network (DDN). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet

Authors: R. Colella, E. Gardner, R. Callon.

Date: July 1991

Formats: txt json pdf html ps

Obsoleted by: RFC 1629

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1237

This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]

RFC 1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542)

Authors: G. Satz.

Date: June 1991

Formats: txt html json

Obsoletes: RFC 1162

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1238

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC 1239 Reassignment of experimental MIBs to standard MIBs

Authors: J.K. Reynolds.

Date: June 1991

Formats: txt html json

Updates: RFC 1229, RFC 1230, RFC 1231, RFC 1232, RFC 1233

Status: HISTORIC

DOI: 10.17487/RFC 1239

This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK]

RFC 1240 OSI connectionless transport services on top of UDP: Version 1

Authors: C. Shue, W. Haggerty, K. Dobbins.

Date: June 1991

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1240

This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK]

RFC 1241 Scheme for an internet encapsulation protocol: Version 1

Authors: R.A. Woodburn, D.L. Mills.

Date: July 1991

Formats: txt json pdf ps html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1241

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

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 1243 AppleTalk Management Information Base

Authors: S. Waldbusser.

Date: July 1991

Formats: txt html json

Obsoleted by: RFC 1742

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1243

This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK]

RFC 1244 Site Security Handbook

Authors: J.P. Holbrook, J.K. Reynolds.

Date: July 1991

Formats: txt json html

Obsoleted by: RFC 2196

Status: INFORMATIONAL

DOI: 10.17487/RFC 1244

This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8]

RFC 1245 OSPF Protocol Analysis

Authors: J. Moy.

Date: July 1991

Formats: txt json ps html pdf

Also: RFC 1246, RFC 1247

Status: INFORMATIONAL

DOI: 10.17487/RFC 1245

This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet. This memo provides information for the Internet community. It does not specify any Internet standard.

RFC 1246 Experience with the OSPF Protocol

Authors: J. Moy.

Date: July 1991

Formats: txt pdf html json ps

Also: RFC 1245, RFC 1247

Status: INFORMATIONAL

DOI: 10.17487/RFC 1246

This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. This memo provides information for the Internet community. It does not specify any Internet standard.

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 1249 DIXIE Protocol Specification

Authors: T. Howes, M. Smith, B. Beecher.

Date: August 1991

Formats: txt json html

Also: RFC 1202

Status: INFORMATIONAL

DOI: 10.17487/RFC 1249

This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. This memo provides information for the Internet community. It does not specify any standard.

RFC 1250 IAB Official Protocol Standards

Authors: J. Postel.

Date: August 1991

Formats: txt json html

Obsoletes: RFC 1200

Obsoleted by: RFC 2200, RFC 1280

Status: HISTORIC

DOI: 10.17487/RFC 1250

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1251 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members

Authors: G. Malkin.

Date: August 1991

Formats: txt json html

Obsoleted by: RFC 1336

Status: INFORMATIONAL

DOI: 10.17487/RFC 1251

This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9]

RFC 1252 OSPF Version 2 Management Information Base

Authors: F. Baker, R. Coltun.

Date: August 1991

Formats: txt html json

Obsoletes: RFC 1248

Obsoleted by: RFC 1253

Also: RFC 1245, RFC 1247

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1252

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS- TRACK]

RFC 1253 OSPF Version 2 Management Information Base

Authors: F. Baker, R. Coltun.

Date: August 1991

Formats: txt html json

Obsoletes: RFC 1252

Obsoleted by: RFC 1850

Also: RFC 1245, RFC 1246, RFC 1247

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1253

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS- TRACK]

RFC 1254 Gateway Congestion Control Survey

Authors: A. Mankin, K. Ramakrishnan.

Date: August 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1254

The growth of network intensive Internet applications has made gateway congestion control a high priority. The IETF Performance andCongestion Control Working Group surveyed and reviewed gateway congestion control and avoidance approaches. The purpose of this paper is to present our review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication(DEC Bit), and Fair Queueing. The task remains for Internet implementors to determine and agree on the most effective mechanisms for controlling gateway congestion.

RFC 1255 A Naming Scheme for c=US

Authors: The North American Directory Forum.

Date: September 1991

Formats: txt json html

Obsoletes: RFC 1218

Obsoleted by: RFC 1417

Status: INFORMATIONAL

DOI: 10.17487/RFC 1255

This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1256 ICMP Router Discovery Messages

Authors: S. Deering, Ed..

Date: September 1991

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1256

This document specifies an extension of the Internet Control MessageProtocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers.

RFC 1257 Isochronous applications do not require jitter-controlled networks

Authors: C. Partridge.

Date: September 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1257

This memo argues that jitter control is not required for networks to support isochronous applications. A network providing bandwidth and bounds delay is sufficient. The implications for gigabit internetworking protocols are briefly considered.

RFC 1258 BSD Rlogin

Authors: B. Kantor.

Date: September 1991

Formats: txt json html

Obsoleted by: RFC 1282

Status: INFORMATIONAL

DOI: 10.17487/RFC 1258

The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1259 Building the open road: The NREN as test-bed for the national public network

Authors: M. Kapor.

Date: September 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1259

This memo discusses the background and importance of NREN. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1261 Transition of Nic Services

Authors: S. Williamson, L. Nobile.

Date: September 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1261

This memo outlines the transition of NIC Services. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1262 Guidelines for Internet Measurement Activities

Authors: V.G. Cerf.

Date: October 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1262

This RFC represents IAB guidance for researchers considering measurement experiments on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1263 TCP Extensions Considered Harmful

Authors: S. O'Malley, L.L. Peterson.

Date: October 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1263

This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve theInternet protocol suite. Its purpose is to stimulate discussion in the Internet community.

RFC 1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria

Authors: R.M. Hinden.

Date: October 1991

Formats: txt json html

Obsoleted by: RFC 4794

Status: HISTORIC

DOI: 10.17487/RFC 1264

This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard.

RFC 1265 BGP Protocol Analysis

Authors: Y. Rekhter.

Date: October 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1265

This report summarizes the key feature of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1266 Experience with the BGP Protocol

Authors: Y. Rekhter.

Date: October 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1266

The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1267 Border Gateway Protocol 3 (BGP-3)

Authors: K. Lougheed, Y. Rekhter.

Date: October 1991

Formats: txt html json

Obsoletes: RFC 1163

Status: HISTORIC

DOI: 10.17487/RFC 1267

This memo, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC 1268 Application of the Border Gateway Protocol in the Internet

Authors: Y. Rekhter, P. Gross.

Date: October 1991

Formats: txt json html

Obsoletes: RFC 1164

Obsoleted by: RFC 1655

Status: HISTORIC

DOI: 10.17487/RFC 1268

This document, together with its companion document, "A BorderGateway Protocol (BGP-3)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol (BGP-3)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.
Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (iwg@rice.edu).

RFC 1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3

Authors: S. Willis, J.W. Burruss.

Date: October 1991

Formats: txt json html

Obsoleted by: RFC 4273

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1269

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Border Gateway Protocol. [STANDARDS-TRACK]

RFC 1270 SNMP Communications Services

Authors: F. Kastenholz.

Date: October 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1270

This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation. This memo provides information for the Internet community. It does not specify an Internet standard.

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 1272 Internet Accounting: Background

Authors: C. Mills, D. Hirsh, G.R. Ruth.

Date: November 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1272

This document provides background information for the "Internet Accounting Architecture". This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1273 Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations

Authors: M.F. Schwartz.

Date: November 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1273

In this report we discuss plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet. We overview our experimental design, considerations of network and remote site load, mechanisms used to control the measurement collection process, and network appropriate use and privacy issues, including our efforts to inform sites measured by this study. A list of references and information on how to contact the Principal Investigator are included.

RFC 1274 The COSINE and Internet X.500 Schema

Authors: P. Barker, S. Kille.

Date: November 1991

Formats: txt json html

Obsoleted by: RFC 4524

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1274

This document suggests an X.500 Directory Schema, or NamingArchitecture, for use in the COSINE and Internet X.500 pilots. The schema is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processable version of the schema.
This document also proposes a mechanism for allowing the schema to evolve in line with emerging requirements. Proformas to support this process are included.
Corrections and additions to the schema should be sent to na- update@cs.ucl.ac.uk list, as described within.

RFC 1275 Replication Requirements to provide an Internet Directory using X.500

Authors: S.E. Hardcastle-Kille.

Date: November 1991

Formats: txt ps json pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1275

This RFCconsiders certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective openInternet Directory can be established using these protocols and services [CCI88]. The only areas considered are primary problems, to which solutions must be found before a pilot can be deployed. This RFCconcerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation.

RFC 1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500

Authors: S.E. Hardcastle-Kille.

Date: November 1991

Formats: txt ps html json

Status: HISTORIC

DOI: 10.17487/RFC 1276

Some requirements on extensions to X.500 are described in theRFC[HK91b], in order to build an Internet Directory usingX.500(1988). This document specifies a set of solutions to the problems raised. These solutions are based on some work done for the QUIPU implementation, and demonstrated to be effective in a number of directory pilots. By documenting a de facto standard, rapid progress can be made towards a full-scale pilot. These procedures are an INTERIM approach. There are known deficiencies, both in terms of manageability and scalability.Transition to standard approaches are planned when appropriate standards are available. This RFCwill be obsoleted at this point.

RFC 1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers

Authors: S.E. Hardcastle-Kille.

Date: November 1991

Formats: txt ps html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1277

The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSINetwork Layer standards [CCI88] [ISO87a]. The OSI Directory, and any OSI application utilising the OSI Directory must be able use these Network Addresses to identify end systems. Currently, OSI applications are often run over lower layers other than the OSINetwork Service. It is neither reasonable nor desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to be dependent on a globalOSI Network Service. This document defines a new network address format, and rules for using some existing network address formats. The scope of this document is:

RFC 1278 A string encoding of Presentation Address

Authors: S.E. Hardcastle-Kille.

Date: November 1991

Formats: txt json ps html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1278

There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation.

RFC 1279 X.500 and Domains

Authors: S.E. Hardcastle-Kille.

Date: November 1991

Formats: txt json html ps pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1279

This RFCconsiders X.500 in relation to Internet and UK Domains.A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community. There is no current intention to provide an operational replacement for DNS.

RFC 1280 IAB Official Protocol Standards

Authors: J. Postel.

Date: March 1992

Formats: txt json html

Obsoletes: RFC 1250

Obsoleted by: RFC 1360

Status: HISTORIC

DOI: 10.17487/RFC 1280

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1281 Guidelines for the Secure Operation of the Internet

Authors: R. Pethia, S. Crocker, B. Fraser.

Date: November 1991

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1281

The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1282 BSD Rlogin

Authors: B. Kantor.

Date: December 1991

Formats: txt html json

Obsoletes: RFC 1258

Status: INFORMATIONAL

DOI: 10.17487/RFC 1282

This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1283 SNMP over OSI

Authors: M. Rose.

Date: December 1991

Formats: txt html json

Obsoleted by: RFC 1418

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1283

This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard.

RFC 1284 Definitions of Managed Objects for the Ethernet-like Interface Types

Authors: J. Cook, Ed..

Date: December 1991

Formats: txt json html

Obsoleted by: RFC 1398

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1284

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC 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 1286 Definitions of Managed Objects for Bridges

Authors: E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie.

Date: December 1991

Formats: txt html json

Obsoleted by: RFC 1493, RFC 1525

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1286

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK]

RFC 1287 Towards the Future Internet Architecture

Authors: D. Clark, L. Chapin, V. Cerf, R. Braden, R. Hobby.

Date: December 1991

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1287

This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1288 The Finger User Information Protocol

Authors: D. Zimmerman.

Date: December 1991

Formats: txt json html

Obsoletes: RFC 1196, RFC 1194, RFC 0742

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1288

This memo describes the Finger user information protocol. This is a simple protocol which provides an interface to a remote user information program.
Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition.
This edition corrects and clarifies RFC 1196.

RFC 1289 DECnet Phase IV MIB Extensions

Authors: J. Saperia.

Date: December 1991

Formats: txt json html

Obsoleted by: RFC 1559

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1289

This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. When used in conjunction with the structure of management information (RFC 1155), the management information base for network management of TCP/IP-based internets(RFC 1213) and the Simple Network Management Protocol (RFC 1157), it will be possible to provide integrated network management of combinedTCP/IP and DECnet Phase IV based internets. This document was produced by the DECnet Phase IV MIB working group of the InternetEngineering Task Force (IETF).

RFC 1290 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places

Authors: J. Martin.

Date: December 1991

Formats: txt json html

Obsoleted by: RFC 1402

Status: INFORMATIONAL

DOI: 10.17487/RFC 1290

This document was presented at the 1991 ACM SIGUCCS User ServicesConference. It appears here in its updated form.
There is a wealth of information on the network. In fact, so much information, that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users.
The ultimate goal is to make the route to these sources of information invisible to the user. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we can all be richer.

RFC 1291 Mid-Level Networks Potential Technical Services

Authors: V. Aggarwal.

Date: December 1991

Formats: txt json ps html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1291

This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks. The term "mid-level" is used as a generic term to represent all regional and similar networks, which, due to continuous evolutions and transitions, can no longer be termed"regional" [MAN]. It discusses the pros and cons of offering these services, as well as areas in which mid-level networks can work together.
A large portion of the ideas stem from discussions at the IETFOperational Statistics (OPstat), User Connectivity Problems (UCP) andNetwork Joint Management (NJM) working groups.

RFC 1292 A Catalog of Available X.500 Implementations

Authors: R. Lang, R. Wright.

Date: January 1992

Formats: txt html json

Obsoleted by: RFC 1632

Status: INFORMATIONAL

DOI: 10.17487/RFC 1292

The goal of this document is to provide information regarding the availability and capability of implementations of X.500. Comments and critiques of this document, and new or updated descriptions ofX.500 implementations are welcome. Send them to the DirectoryInformation Services Infrastructure (DISI) Working Group(disi@merit.edu) or to the editors.

RFC 1293 Inverse Address Resolution Protocol

Authors: T. Bradley, C. Brown.

Date: January 1992

Formats: txt html json

Obsoleted by: RFC 2390

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1293

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]

RFC 1294 Multiprotocol Interconnect over Frame Relay

Authors: T. Bradley, C. Brown, A. Malis.

Date: January 1992

Formats: txt json html

Obsoleted by: RFC 1490, RFC 2427

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1294

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]

RFC 1295 User Bill of Rights for entries and listings in the Public Directory

Authors: The North American Directory Forum.

Date: January 1992

Formats: txt json html

Obsoleted by: RFC 1417

Status: INFORMATIONAL

DOI: 10.17487/RFC 1295

This RFC is a near-verbatim copy of a document, known as NADF-265, which has been produced by the North American Directory Forum (NADF).
User Bill of Rights for entries and listings in the Public Directory
The mission of the North American Directory Forum is to provide interconnected electronic directories which empower users with unprecedented access to public information. To address significant security and privacy issues, the North American Directory Forum introduces the following "User Bill of Rights" for entries in thePublic Directory. As a user, you have:
I. The right not to be listed.
II. The right to have you or your agent informed when your entry is created.
III. The right to examine your entry.
IV. The right to correct inaccurate information in your entry.
V. The right to remove specific information from your entry.
VI. The right to be assured that your listing in thePublic Directory will comply with US or Canadian law regulating privacy or access information.
VII. The right to expect timely fulfillment of these rights.

RFC 1296 Internet Growth (1981-1991)

Authors: M. Lottor.

Date: January 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1296

This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables.DNS entries are collected by a program called ZONE, which searches the Internet and retrieves data from all known domains. Pre-DNS host table data were retrieved from system archive tapes. Various statistics are presented on the number of hosts and domains.

RFC 1297 NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS")

Authors: D. Johnson.

Date: January 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1297

Professional quality handling of network problems requires some kind of problem tracking system, herein referred to as a "trouble ticket" system. A basic trouble ticket system acts like a hospital chart, coordinating the work of multiple people who may need to work on the problem.
Once the basic trouble ticket system is in place, however, there are many extensions that can aid Network Operations efficiency.Information in the tickets can be used to produce statistical reports. Operator efficiency and accuracy may be increased by automating trouble ticket entry with information from the networkAlert system. The Alert system may be used to monitor trouble ticket progress. Trouble tickets may be also used to communicate network health information between NOCs, to telcom vendors, and to other internal sales and engineering audiences.
This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers.

RFC 1298 SNMP over IPX

Authors: R. Wormley, S. Bostock.

Date: February 1992

Formats: txt json html

Obsoleted by: RFC 1420

Status: INFORMATIONAL

DOI: 10.17487/RFC 1298

This memo defines a convention for encapsulating Simple NetworkManagement Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2].

RFC 1299 Summary of 1200-1299

Authors: M. Kennedy.

Date: January 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1299

RFC 1300 Remembrances of Things Past

Authors: S. Greenfield.

Date: February 1992

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1300

Poem. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1301 Multicast Transport Protocol

Authors: S. Armstrong, A. Freier, K. Marzullo.

Date: February 1992

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1301

This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1302 Building a Network Information Services Infrastructure

Authors: D. Sitzler, P. Smith, A. Marine.

Date: February 1992

Formats: txt html json

Also: FYI 0012

Status: INFORMATIONAL

DOI: 10.17487/RFC 1302

This FYI RFC document is intended for existing Internet NetworkInformation Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities. The document strives to:
- Define a basic set of essential services that NetworkInformation Centers (NICs) will provide to Internet users, including new mechanisms that will facilitate the timely dissemination of information to the Internet community and encourage cooperation among NICs.
- Describe existing NIC services as an aid to Internet users and as a model for organizations establishing new NICs.

RFC 1303 A Convention for Describing SNMP-based Agents

Authors: K. McCloghrie, M. Rose.

Date: February 1992

Formats: txt html json

Also: RFC 1155, RFC 1157, RFC 1212, RFC 1213

Status: INFORMATIONAL

DOI: 10.17487/RFC 1303

This memo suggests a straight-forward approach towards describingSNMP-based agents.

RFC 1304 Definitions of Managed Objects for the SIP Interface Type

Authors: T. Cox, Ed., K. Tesink, Ed..

Date: February 1992

Formats: txt json html

Obsoleted by: RFC 1694

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1304

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing SIP (SMDS InterfaceProtocol) objects.

RFC 1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis

Authors: D. Mills.

Date: March 1992

Formats: txt json tar html pdf

Obsoletes: RFC 0958, RFC 1059, RFC 1119

Obsoleted by: RFC 5905

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1305

This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK]

RFC 1306 Experiences Supporting By-Request Circuit-Switched T3 Networks

Authors: A. Nicholson, J. Young.

Date: March 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1306

This memo describes the experiences of a project team at CrayResearch, Inc., in implementing support for circuit-switched T3 services. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.
Developers at Cray Research, Inc. were presented with an opportunity to use a circuit-switched T3 network for wide area networking. They devised an architectural model for using this new resource. This involves activating the circuit-switched connection when an application program engages in a bulk data transfer, and releasing the connection when the transfer is complete.
Three software implementations for this feature have been tested, and the results documented here. A variety of issues are involved, and further research is necessary. Network users are beginning to recognize the value of this service, and are planning to make use of by-request circuit-switched networks. A standard method of access will be needed to ensure interoperability among vendors of circuit- switched network support products.

RFC 1307 Dynamically Switched Link Control Protocol

Authors: J. Young, A. Nicholson.

Date: March 1992

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1307

This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit- switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. It is documented here for the benefit of others who may wish to perform further research.
While working with circuit-switched T3 networks, developers at CrayResearch, Inc., defined a model wherein a host would generate control messages for a network switch. This work is described in RFC 1306,"Experiences Supporting By-Request Circuit-Switched T3 Networks". In order to simplify the model it was decided that the inconsistencies of switch control should be hidden from the host generating the control messages. To that end, a protocol was defined and implemented. This RFC documents the Dynamically Switched LinkControl Protocol (DSLCP), which is used for creation and control of downstream network links by a host.

RFC 1308 Executive Introduction to Directory Services Using the X.500 Protocol

Authors: C. Weider, J. Reynolds.

Date: March 1992

Formats: txt json html

Also: FYI 0013

Status: INFORMATIONAL

DOI: 10.17487/RFC 1308

This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500.
This FYI RFC is a product of the Directory Information Services(pilot) Infrastructure Working Group (DISI). A combined effort of the User Services and the OSI Integration Areas of the InternetEngineering Task Force (IETF).

RFC 1309 Technical Overview of Directory Services Using the X.500 Protocol

Authors: C. Weider, J. Reynolds, S. Heker.

Date: March 1992

Formats: txt json html

Also: FYI 0014

Status: INFORMATIONAL

DOI: 10.17487/RFC 1309

This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts DirectoryServices based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information.
A primary purpose of this paper is to illustrate the vast functionality of the X.500 protocol and to show how it can be used to provide a global directory for human use, and can support other applications which would benefit from directory services, such as main programs.
This FYI RFC is a product of the Directory Information Services(pilot) Infrastructure Working Group (DISI). A combined effort of the User Services and the OSI Integration Areas of the InternetEngineering Task Force (IETF).

RFC 1310 The Internet Standards Process

Authors: L. Chapin.

Date: March 1992

Formats: txt json html

Obsoleted by: RFC 1602

Status: INFORMATIONAL

DOI: 10.17487/RFC 1310

This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]

RFC 1311 Introduction to the STD Notes

Authors: J. Postel.

Date: March 1992

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1311

The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS- TRACK]

RFC 1312 Message Send Protocol 2

Authors: R. Nelson, G. Arnold.

Date: April 1992

Formats: txt html json

Obsoletes: RFC 1159

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1312

The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community.

RFC 1313 Today's Programming for KRFC AM 1313 Internet Talk Radio

Authors: C. Partridge.

Date: 1 April 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1313

Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1314 A File Format for the Exchange of Images in the Internet

Authors: A. Katz, D. Cohen.

Date: April 1992

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1314

This document defines a standard file format for the exchange of fax-like black and white images within the Internet. It is a product of the Network Fax Working Group of the Internet Engineering TaskForce (IETF).
The standard is:
** The file format should be TIFF-B with multi-page files supported. Images should be encoded as one TIFF strip per page.
** Images should be compressed using MMR when possible. Images may also be MH or MR compressed or uncompressed. If MH or MR compression is used, scan lines should be "byte-aligned".
** For maximum interoperability, image resolutions should either be 600, 400, or 300 dpi; or else be one of the standard Group 3 fax resolutions (98 or 196 dpi vertically and 204 dpi horizontally).
Note that this specification is self contained and an implementation should be possible without recourse to the TIFF references, and that only the specific TIFF documents cited are relevant to this specification. Updates to the TIFF documents do not change this specification.
Experimentation with this file format specified here is encouraged.

RFC 1315 Management Information Base for Frame Relay DTEs

Authors: C. Brown, F. Baker, C. Carvalho.

Date: April 1992

Formats: txt json html

Obsoleted by: RFC 2115

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1315

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing Frame Relay.

RFC 1316 Definitions of Managed Objects for Character Stream Devices

Authors: B. Stewart.

Date: April 1992

Formats: txt html json

Obsoleted by: RFC 1658

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1316

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for the management of character stream devices. [STANDARDS-TRACK]

RFC 1317 Definitions of Managed Objects for RS-232-like Hardware Devices

Authors: B. Stewart.

Date: April 1992

Formats: txt html json

Obsoleted by: RFC 1659

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1317

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]

RFC 1318 Definitions of Managed Objects for Parallel-printer-like Hardware Devices

Authors: B. Stewart.

Date: April 1992

Formats: txt json html

Obsoleted by: RFC 1660

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1318

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of parallel-printer- like devices. [STANDARDS-TRACK]

RFC 1319 The MD2 Message-Digest Algorithm

Authors: B. Kaliski.

Date: April 1992

Formats: txt json html

Obsoleted by: RFC 6149

Status: HISTORIC

DOI: 10.17487/RFC 1319

This document describes the MD2 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1320 The MD4 Message-Digest Algorithm

Authors: R. Rivest.

Date: April 1992

Formats: txt json html

Obsoletes: RFC 1186

Obsoleted by: RFC 6150

Status: HISTORIC

DOI: 10.17487/RFC 1320

This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 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 1322 A Unified Approach to Inter-Domain Routing

Authors: D. Estrin, Y. Rekhter, S. Hotz.

Date: May 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1322

This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. The focus is on scalability to very large networks and functionality, as well as scalability, to support routing in an environment of heterogeneous services, requirements, and route selection criteria.
Note: The work of D. Estrin and S. Hotz was supported by the NationalScience Foundation under contract number NCR-9011279, with matching funds from GTE Laboratories. The work of Y. Rekhter was supported by the Defense Advanced Research Projects Agency, under contractDABT63-91-C-0019. Views and conclusions expressed in this paper are not necessarily those of the Defense Advanced Research ProjectsAgency and National Science Foundation.

RFC 1323 TCP Extensions for High Performance

Authors: V. Jacobson, R. Braden, D. Borman.

Date: May 1992

Formats: txt html json

Obsoletes: RFC 1072, RFC 1185

Obsoleted by: RFC 7323

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1323

This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms:RTTM (Round Trip Time Measurement) and PAWS (Protect Against WrappedSequences). Selective acknowledgments are not included in this memo.
This memo combines and supersedes RFC-1072 and RFC-1185, adding additional clarification and more detailed specification. Appendix C summarizes the changes from the earlier RFCs.

RFC 1324 A Discussion on Computer Network Conferencing

Authors: D. Reed.

Date: May 1992

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1324

This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. It is also the intention of this memo to stimulate the computer community and generate some useful discussion about the merits of this field.

RFC 1325 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions

Authors: G. Malkin, A. Marine.

Date: May 1992

Formats: txt json html

Obsoletes: RFC 1206

Obsoleted by: RFC 1594

Status: INFORMATIONAL

DOI: 10.17487/RFC 1325

This FYI RFC is one of two FYI's called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet.

RFC 1326 Mutual Encapsulation Considered Dangerous

Authors: P. Tsuchiya.

Date: May 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1326

This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A).

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 1328 X.400 1988 to 1984 downgrading

Authors: S. Hardcastle-Kille.

Date: May 1992

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1328

This document considers issues of downgrading from X.400(1988) toX.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components. This document defines a number of extensions to this annexe.
This specification is not tutorial. COSINE Study 8.2 by J.A.I.Craigie gives a useful overview [Cra88].

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 1330 Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community

Authors: ESCC X.500/X.400 Task Force, ESnet Site Coordinating Comittee (ESCC), Energy Sciences Network (ESnet).

Date: May 1992

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1330

This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links

Authors: W. Simpson.

Date: May 1992

Formats: txt json html

Obsoletes: RFC 1171, RFC 1172

Obsoleted by: RFC 1548

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1331

The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is comprised of three main components:
1. A method for encapsulating datagrams over serial links.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the PPP encapsulation scheme, together with thePPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions.
This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.

RFC 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 1333 PPP Link Quality Monitoring

Authors: W. Simpson.

Date: May 1992

Formats: txt html json

Obsoleted by: RFC 1989

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1333

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link.
This document defines a protocol for generating Link-Quality-Reports.
This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.

RFC 1334 PPP Authentication Protocols

Authors: B. Lloyd, W. Simpson.

Date: October 1992

Formats: txt json html

Obsoleted by: RFC 1994

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1334

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
This document defines two protocols for Authentication: the PasswordAuthentication Protocol and the Challenge-Handshake AuthenticationProtocol. This memo is the product of the Point-to-Point ProtocolWorking Group of the Internet Engineering Task Force (IETF).Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.

RFC 1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion

Authors: Z. Wang, J. Crowcroft.

Date: May 1992

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1335

This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for theInternet. This is an "idea" paper and discussion is strongly encouraged.

RFC 1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members

Authors: G. Malkin.

Date: May 1992

Formats: txt html json

Obsoletes: RFC 1251

Also: FYI 0009

Status: INFORMATIONAL

DOI: 10.17487/RFC 1336

This FYI RFC contains biographical information about members of theInternet Activities Board (IAB), the Internet Engineering SteeringGroup (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet ResearchTask Force (IRTF).

RFC 1337 TIME-WAIT Assassination Hazards in TCP

Authors: R. Braden.

Date: May 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1337

This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified.

RFC 1338 Supernetting: an Address Assignment and Aggregation Strategy

Authors: V. Fuller, T. Li, J. Yu, K. Varadhan.

Date: June 1992

Formats: txt json html

Obsoleted by: RFC 1519

Status: INFORMATIONAL

DOI: 10.17487/RFC 1338

This memo discusses strategies for address assignment of the existingIP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers.

RFC 1339 Remote Mail Checking Protocol

Authors: S. Dorner, P. Resnick.

Date: June 1992

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1339

This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user.

RFC 1340 Assigned Numbers

Authors: J. Reynolds, J. Postel.

Date: July 1992

Formats: txt html json

Obsoletes: RFC 1060

Obsoleted by: RFC 1700

Status: HISTORIC

DOI: 10.17487/RFC 1340

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.

RFC 1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies

Authors: N. Borenstein, N. Freed.

Date: June 1992

Formats: txt html pdf json ps

Obsoleted by: RFC 1521

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1341

This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. [STANDARDS-TRACK]

RFC 1342 Representation of Non-ASCII Text in Internet Message Headers

Authors: K. Moore.

Date: June 1992

Formats: txt json html

Obsoleted by: RFC 1522

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1342

This memo describes an extension to the message format defined in [1](known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC822 message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1341.

RFC 1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information

Authors: N. Borenstein.

Date: June 1992

Formats: txt json pdf html ps

Status: INFORMATIONAL

DOI: 10.17487/RFC 1343

This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1344 Implications of MIME for Internet Mail Gateways

Authors: N. Borenstein.

Date: June 1992

Formats: txt html pdf json ps

Status: INFORMATIONAL

DOI: 10.17487/RFC 1344

While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME. These opportunities are the subject of this memo. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1345 Character Mnemonics and Character Sets

Authors: K. Simonsen.

Date: June 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1345

This memo lists a selection of characters and their presence in some coded character sets. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1346 Resource Allocation, Control, and Accounting for the Use of Network Resources

Authors: P. Jones.

Date: June 1992

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1346

The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular. No solution discussed in this document is intended as a standard. Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing

Authors: R. Callon.

Date: June 1992

Formats: txt json pdf ps html

Status: HISTORIC

DOI: 10.17487/RFC 1347

This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1348 DNS NSAP RRs

Authors: B. Manning.

Date: July 1992

Formats: txt html json

Obsoleted by: RFC 1637

Updates: RFC 1034, RFC 1035

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1348

This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community.

RFC 1349 Type of Service in the Internet Protocol Suite

Authors: P. Almquist.

Date: July 1992

Formats: txt html json

Obsoleted by: RFC 2474

Updates: RFC 1248, RFC 1247, RFC 1195, RFC 1123, RFC 1122, RFC 1060, RFC 0791

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1349

This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]

RFC 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 1351 SNMP Administrative Model

Authors: J. Davin, J. Galvin, K. McCloghrie.

Date: July 1992

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1351

This memo presents an elaboration of the SNMP administrative model set forth in [1]. This model provides a unified conceptual basis for administering SNMP protocol entities to support: authenticaiton and integrity, privacy, access control, and cooperation of protocol entities. [STANDARDS-TRACK]

RFC 1352 SNMP Security Protocols

Authors: J. Galvin, K. McCloghrie, J. Davin.

Date: July 1992

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1352

The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK]

RFC 1353 Definitions of Managed Objects for Administration of SNMP Parties

Authors: K. McCloghrie, J. Davin, J. Galvin.

Date: July 1992

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1353

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 describes a representation of the SNMP parties defined in [8] as objects defined according to the Internet StandardSMI [1]. These definitions are consistent with the SNMP Security protocols set forth in [9].

RFC 1354 IP Forwarding Table MIB

Authors: F. Baker.

Date: July 1992

Formats: txt html json

Obsoleted by: RFC 2096

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1354

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing routes in the IPInternet.
It is proposed that the ipRouteTable defined by MIB-II (RFC 1213) be deprecated and replaced with this table. This adds the ability to set or display multi-path routes, and varying routes by network management policy.

RFC 1355 Privacy and Accuracy Issues in Network Information Center Databases

Authors: J. Curran, A. Marine.

Date: August 1992

Formats: txt html json

Also: FYI 0015

Status: INFORMATIONAL

DOI: 10.17487/RFC 1355

This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases. The purpose is to formalize procedures for the responsible handling of the personal and organizational information maintained by NICs in publically accessible databases, and to improve the accuracy and accessibility of such data where appropriate.

RFC 1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode

Authors: A. Malis, D. Robinson, R. Ullmann.

Date: August 1992

Formats: txt json html

Obsoletes: RFC 0877

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1356

This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment withISO/IEC and CCITT standards. It is a replacement for RFC 877, "AStandard for the Transmission of IP Datagrams Over Public DataNetworks" [1].
It was written to correct several ambiguities in the InternetStandard for IP/X.25 (RFC 877), to align it with ISO/IEC standards that have been written following RFC 877, to allow interoperable multiprotocol operation between routers and bridges over X.25, and to add some additional remarks based upon practical experience with the specification over the 8 years since that RFC.
The substantive change to the IP encapsulation is an increase in the allowed IP datagram Maximum Transmission Unit from 576 to 1600, to reflect existing practice.
This document also specifies the Internet encapsulation for protocols, including IP, on the packet mode of the ISDN. It applies to the use of Internet protocols on the ISDN in the circuit mode only when the circuit is established as an end-to-end X.25 connection.

RFC 1357 A Format for E-mailing Bibliographic Records

Authors: D. Cohen.

Date: July 1992

Formats: txt json html

Obsoleted by: RFC 1807

Status: INFORMATIONAL

DOI: 10.17487/RFC 1357

This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR).

RFC 1358 Charter of the Internet Architecture Board (IAB)

Authors: L. Chapin.

Date: August 1992

Formats: txt html json

Obsoleted by: RFC 1601

Status: INFORMATIONAL

DOI: 10.17487/RFC 1358

The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1359 Connecting to the Internet - What Connecting Institutions Should Anticipate

Authors: ACM SIGUCCS.

Date: August 1992

Formats: txt html json

Also: FYI 0016

Status: INFORMATIONAL

DOI: 10.17487/RFC 1359

This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to theInternet.
In order to provide clarity to the reader, some specific information has been detailed. In doing so, the document has been directed toward U.S. academic institutions that have not yet connected to theInternet.
However, the issues for which specific information has been provided can be generalized for any organization that wishes to participate in the world-wide Internet community. It will be necessary for those organizations to obtain the correct and detailed information from their local or national IP service providers. In addition, this document may be used as an evaluation checklist for organizations that are currently connected. Readers are expected to have general familiarity with networking concepts and terminology.

RFC 1360 IAB Official Protocol Standards

Authors: J. Postel.

Date: September 1992

Formats: txt html json

Obsoletes: RFC 1280

Obsoleted by: RFC 1410

Status: HISTORIC

DOI: 10.17487/RFC 1360

RFC 1361 Simple Network Time Protocol (SNTP)

Authors: D. Mills.

Date: August 1992

Formats: txt html json

Obsoleted by: RFC 1769

Also: RFC 1305

Status: INFORMATIONAL

DOI: 10.17487/RFC 1361

This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless RPC mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
This memorandum does not obsolete or update any RFC. A working knowledge of RFC-1305 is not required for an implementation of SNTP.

RFC 1362 Novell IPX over Various WAN Media (IPXWAN)

Authors: M. Allen.

Date: September 1992

Formats: txt json html

Obsoleted by: RFC 1634

Status: INFORMATIONAL

DOI: 10.17487/RFC 1362

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks.

RFC 1363 A Proposed Flow Specification

Authors: C. Partridge.

Date: September 1992

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1363

A flow specification (or "flow spec") is a data structure used by internetwork hosts to request special services of the internetwork, often guarantees about how the internetwork will handle some of the hosts' traffic. In the future, hosts are expected to have to request such services on behalf of distributed applications such as multimedia conferencing.
The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only). This RFC is a product of the Internet Research Task Force (IRTF).

RFC 1364 BGP OSPF Interaction

Authors: K. Varadhan.

Date: September 1992

Formats: txt html json

Obsoleted by: RFC 1403

Also: RFC 1247, RFC 1267

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1364

This memo defines the various criteria to be used when designingAutonomous System Border Routers (ASBR) that will run BGP with otherASBRs external to the AS and OSPF as its IGP.

RFC 1365 An IP Address Extension Proposal

Authors: K. Siyan.

Date: September 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1365

This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements.

RFC 1366 Guidelines for Management of IP Address Space

Authors: E. Gerich.

Date: October 1992

Formats: txt json html

Obsoleted by: RFC 1466

Status: INFORMATIONAL

DOI: 10.17487/RFC 1366

This document has been reviewed by the Federal Engineering Task Force(FEPG) on behalf of the Federal Networking Council (FNC), the co- chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space.

RFC 1367 Schedule for IP Address Space Management Guidelines

Authors: C. Topolcic.

Date: October 1992

Formats: txt json html

Obsoleted by: RFC 1467

Status: INFORMATIONAL

DOI: 10.17487/RFC 1367

This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices

Authors: D. McMaster, K. McCloghrie.

Date: October 1992

Formats: txt html json

Obsoleted by: RFC 1516

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1368

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing IEEE 802.3 10Mb/second baseband repeaters, sometimes referred to as "hubs."

RFC 1369 Implementation Notes and Experience for the Internet Ethernet MIB

Authors: F. Kastenholz.

Date: October 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1369

This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1370 Applicability Statement for OSPF

Authors: Internet Architecture Board, L. Chapin.

Date: October 1992

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1370

This Applicability Statement places a requirement on vendors claiming conformance to this standard, in order to assure that users will have the option of deploying OSPF when they need a multivendor, interoperable IGP in their environment. [STANDARDS-TRACK]

RFC 1371 Choosing a Common IGP for the IP Internet

Authors: P. Gross.

Date: October 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1371

This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to theIAB for a single "common IGP" for the IP portions of the Internet.
In this memo, the term "common IGP" is defined, the need for a commonIGP is explained, the relation of this issue to other ongoingInternet Engineering Task Force (IETF) routing protocol development is provided, and the relation of this issue to the goal for multi- protocol integration in the Internet is explored.
Finally, a specific IGP is recommended as the "common IGP" for IP portions of the Internet -- the Open Shortest Path First (OSPF) routing protocol.
The goal of this recommendation is for all vendors of Internet IP routers to make OSPF available as one of the IGP's provided with their routers.

RFC 1372 Telnet Remote Flow Control Option

Authors: C. Hedrick, D. Borman.

Date: October 1992

Formats: txt json html

Obsoletes: RFC 1080

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1372

This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK]

RFC 1373 Portable DUAs

Authors: T. Tignor.

Date: October 1992

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1373

This document comes in two parts. The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory. The second part is for ISODE-maintainers wishing to provide portable DUAs to users. This part gives instructions in a similar but longer, step-by-step format. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1374 IP and ARP on HIPPI

Authors: J. Renwick, A. Nicholson.

Date: October 1992

Formats: txt html json

Obsoleted by: RFC 2834

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1374

The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP onHIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks.

RFC 1375 Suggestion for New Classes of IP Addresses

Authors: P. Robinson.

Date: October 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1375

This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address.

RFC 1376 The PPP DECnet Phase IV Control Protocol (DNCP)

Authors: S. Senum.

Date: November 1992

Formats: txt json html

Obsoleted by: RFC 1762

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1376

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the NCP for establishing and configuringDigital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.).

RFC 1377 The PPP OSI Network Layer Control Protocol (OSINLCP)

Authors: D. Katz.

Date: November 1992

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1377

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 OSINetwork Layer Protocols.
This memo is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.

RFC 1378 The PPP AppleTalk Control Protocol (ATCP)

Authors: B. Parker.

Date: November 1992

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1378

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 theAppleTalk Protocol [3] over PPP.
This memo is a joint effort of the AppleTalk-IP Working Group and thePoint-to-Point Protocol Working Group of the Internet EngineeringTask Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.

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 1380 IESG Deliberations on Routing and Addressing

Authors: P. Gross, P. Almquist.

Date: November 1992

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1380

This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the InternetEngineering Task Force (IETF).
It also provides a preliminary report of the Internet EngineeringSteering Group (IESG) deliberations on how these routing and addressing issues should be pursued in the Internet ArchitectureBoard (IAB)/IETF.

RFC 1381 SNMP MIB Extension for X.25 LAPB

Authors: D. Throop, F. Baker.

Date: November 1992

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1381

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the Link Layer ofX.25, LAPB. The objects defined here, along with the objects in the"SNMP MIB Extension for the Packet Layer of X.25" [9] and the"Definitions of Managed Objects for RS-232-like Hardware Devices"[8], combine to allow management of an X.25 protocol stack.

RFC 1382 SNMP MIB Extension for the X.25 Packet Layer

Authors: D. Throop, Ed..

Date: November 1992

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1382

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the Packet Layer ofX.25. The objects defined here, along with the objects in the "SNMPMIB Extension for LAPB" [9] and the "Definitions of Managed Objects for RS-232-like Hardware Devices" [8], combine to allow management of an X.25 protocol stack.

RFC 1383 An Experiment in DNS Based IP Routing

Authors: C. Huitema.

Date: December 1992

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1383

Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community.

RFC 1384 Naming Guidelines for Directory Pilots

Authors: P. Barker, S.E. Hardcastle-Kille.

Date: January 1993

Formats: txt ps html pdf json

Obsoleted by: RFC 1617, RTR_0011

Status: INFORMATIONAL

DOI: 10.17487/RFC 1384

Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming guidelines.Alignment to these guidelines is recommended for directory pilots.

RFC 1385 EIP: The Extended Internet Protocol

Authors: Z. Wang.

Date: November 1992

Formats: txt html json

Obsoleted by: RFC 6814

Status: HISTORIC

DOI: 10.17487/RFC 1385

EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1386 The US Domain

Authors: A. Cooper, J. Postel.

Date: December 1992

Formats: txt json html

Obsoleted by: RFC 1480

Status: INFORMATIONAL

DOI: 10.17487/RFC 1386

This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1387 RIP Version 2 Protocol Analysis

Authors: G. Malkin.

Date: January 1993

Formats: txt json html

Obsoleted by: RFC 1721

Status: INFORMATIONAL

DOI: 10.17487/RFC 1387

As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience.

RFC 1388 RIP Version 2 Carrying Additional Information

Authors: G. Malkin.

Date: January 1993

Formats: txt html json

Obsoleted by: RFC 1723

Updates: RFC 1058

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1388

This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP packets and to add a measure of security.A companion document will define the SNMP MIB objects for RIP-2 [2].

RFC 1389 RIP Version 2 MIB Extensions

Authors: G. Malkin, F. Baker.

Date: January 1993

Formats: txt html json

Obsoleted by: RFC 1724

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1389

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing RIP Version 2.

RFC 1390 Transmission of IP and ARP over FDDI Networks

Authors: D. Katz.

Date: January 1993

Formats: txt html json

Also: STD 0036

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1390

This memo defines a method of encapsulating the Internet Protocol(IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks.
This RFC is the product of the IP over FDDI Working Group of theInternet Engineering Task Force (IETF).

RFC 1391 The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force

Authors: G. Malkin.

Date: January 1993

Formats: txt html json

Obsoleted by: RFC 1539

Status: INFORMATIONAL

DOI: 10.17487/RFC 1391

Over the last two years, the attendance at Internet Engineering TaskForce (IETF) Plenary meetings has grown phenomenally. Approximately38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.

RFC 1392 Internet Users' Glossary

Authors: G. Malkin, T. LaQuey Parker.

Date: January 1993

Formats: txt json html

Obsoleted by: RFC 1983

Status: INFORMATIONAL

DOI: 10.17487/RFC 1392

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them.

RFC 1393 Traceroute Using an IP Option

Authors: G. Malkin.

Date: January 1993

Formats: txt json html

Obsoleted by: RFC 6814

Status: HISTORIC

DOI: 10.17487/RFC 1393

Traceroute serves as a valuable network debugging tool. The way in which it is currently implemented has the advantage of being automatically supported by all of the routers. It's two problems are the number of packets it generates and the amount of time it takes to run.
This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time.

RFC 1394 Relationship of Telex Answerback Codes to Internet Domains

Authors: P. Robinson.

Date: January 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1394

This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers. It also lists the telex code and international dialing code, wherever it is available.It will also list major Internet "Public" E-Mail addresses.
This list is designed to show the corresponding codes for Fax and voice messages, telex country codes, telex answerbacks and Internet domains. It is an attempt to place all of the information into one list and all the connections for each country.

RFC 1395 BOOTP Vendor Information Extensions

Authors: J. Reynolds.

Date: January 1993

Formats: txt html json

Obsoletes: RFC 1084, RFC 1048

Obsoleted by: RFC 1497, RFC 1533

Updates: RFC 0951

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1395

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP).

RFC 1396 The Process for Organization of Internet Standards Working Group (POISED)

Authors: S. Crocker.

Date: January 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1396

This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992. Necessarily, this synopsis represents my own perception, particularly for the "prehistory" period. Quite a few people hold strong views about both the overall sequence and specific events. My intent here is to convey as neutral a point of view as possible.

RFC 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol

Authors: D. Haskin.

Date: January 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1397

This document specifies the recommendation of the BGP Working Group on default route advertisement support in BGP2 [1] and BGP3 [2] versions of the Border Gateway Protocol.
This recommendation only applies to BGP2 and BGP3 versions of theBorder Gateway Protocol since starting with the BGP4 [3] version a default route advertisement capability is built in the protocol.

RFC 1398 Definitions of Managed Objects for the Ethernet-Like Interface Types

Authors: F. Kastenholz.

Date: January 1993

Formats: txt html json

Obsoletes: RFC 1284

Obsoleted by: RFC 1623

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1398

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing ethernet-like objects.

RFC 1399 Summary of 1300-1399

Authors: J. Elliott.

Date: January 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1399

RFC 1400 Transition and Modernization of the Internet Registration Service

Authors: S. Williamson.

Date: March 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1400

As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1401 Correspondence between the IAB and DISA on the use of DNS

Authors: Internet Architecture Board.

Date: January 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1401

This memo reproduces three letters exchanged between the InternetActivities Board (IAB) and the Defense Information Systems Agency(DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as "hosts.txt".

RFC 1402 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places

Authors: J. Martin.

Date: January 1993

Formats: txt json html

Obsoletes: RFC 1290

Also: FYI 0010

Status: INFORMATIONAL

DOI: 10.17487/RFC 1402

A wealth of information exists on the network. In fact, there is so much information that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be useful.
The ultimate goal is to make the route to these sources of information invisible to you. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer.

RFC 1403 BGP OSPF Interaction

Authors: K. Varadhan.

Date: January 1993

Formats: txt json html

Obsoletes: RFC 1364

Status: HISTORIC

DOI: 10.17487/RFC 1403

This memo defines the various criteria to be used when designing anAutonomous System Border Routers (ASBR) that will run BGP with otherASBRs external to the AS and OSPF as its IGP. This is a republication of RFC 1364 to correct some editorial problems.

RFC 1404 A Model for Common Operational Statistics

Authors: B. Stockman.

Date: January 1993

Formats: txt html json

Obsoleted by: RFC 1857

Status: INFORMATIONAL

DOI: 10.17487/RFC 1404

This memo describes a model for operational statistics in theInternet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats.

RFC 1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)

Authors: C. Allocchio.

Date: January 1993

Formats: txt html json

Obsoleted by: RFC 2162

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1405

This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 )Recommendations on Message Handling Systems, and systems running theMail-11 (also known as DECnet mail) protocol. The specifications are valid within DECnet Phase IV addressing and routing scheme.
The complete scenario of X.400 / RFC822 / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.
This document covers mainly the O/R address to DECnet from/to address mapping (and vice versa); other mappings are based on RFC 1327 and its eventual future updates.
This is a combined effort of COSINE S2.2, the RARE MSG Working Group, and the IETF X.400 Ops Working Group.

RFC 1406 Definitions of Managed Objects for the DS1 and E1 Interface Types

Authors: F. Baker, Ed., J. Watt, Ed..

Date: January 1993

Formats: txt json html

Obsoletes: RFC 1232

Obsoleted by: RFC 2495

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1406

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links.
This document entirely replaces RFC 1232, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges. The magnitude of the change required is sufficient that virtually every object changed. Therefore, theMIB documented in RFC 1232 should not be implemented.

RFC 1407 Definitions of Managed Objects for the DS3/E3 Interface Type

Authors: T. Cox, K. Tesink.

Date: January 1993

Formats: txt json html

Obsoletes: RFC 1233

Obsoleted by: RFC 2496

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1407

This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3Interfaces. This document is a companion document with Definitions of Managed Objects for the DS1 Interface Type.
This document entirely replaces RFC 1233, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges. The magnitude of the change required is sufficient that virtually every object changed. Therefore, theMIB documented in RFC 1233 should not be implemented.

RFC 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 1409 Telnet Authentication Option

Authors: D. Borman, Ed..

Date: January 1993

Formats: txt html json

Obsoleted by: RFC 1416

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1409

This memo defines an Experimental Protocol for the Internet community.

RFC 1410 IAB Official Protocol Standards

Authors: J. Postel, Ed..

Date: March 1993

Formats: txt html json

Obsoletes: RFC 1360

Obsoleted by: RFC 1500

Status: HISTORIC

DOI: 10.17487/RFC 1410

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).

RFC 1411 Telnet Authentication: Kerberos Version 4

Authors: D. Borman, Ed..

Date: January 1993

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1411

This memo defines an Experimental Protocol for the Internet community.

RFC 1412 Telnet Authentication: SPX

Authors: K. Alagappan.

Date: January 1993

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1412

This memo defines an Experimental Protocol for the Internet community.

RFC 1413 Identification Protocol

Authors: M. St. Johns.

Date: February 1993

Formats: txt json html

Obsoletes: RFC 0931

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1413

The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK]

RFC 1414 Identification MIB

Authors: M. St. Johns, M. Rose.

Date: February 1993

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1414

This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1].This document is a product of the TCP Client Identity ProtocolWorking Group of the Internet Engineering Task Force (IETF).

RFC 1415 FTP-FTAM Gateway Specification

Authors: J. Mindel, R. Slaski.

Date: January 1993

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1415

This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols.
Two key assumptions are made: 1) POSIX file naming conventions and hierarchical organization, rather than proprietary conventions are in use; and 2) X.500 Directory Services are available.

RFC 1416 Telnet Authentication Option

Authors: D. Borman, Ed..

Date: February 1993

Formats: txt json html

Obsoletes: RFC 1409

Obsoleted by: RFC 2941

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1416

This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community.

RFC 1417 NADF Standing Documents: A Brief Overview

Authors: The North American Directory Forum.

Date: February 1993

Formats: txt json html

Obsoletes: RFC 1295, RFC 1255, RFC 1218

Obsoleted by: RFC 1758

Status: INFORMATIONAL

DOI: 10.17487/RFC 1417

The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1418 SNMP over OSI

Authors: M. Rose.

Date: March 1993

Formats: txt html json

Obsoletes: RFC 1161, RFC 1283

Status: HISTORIC

DOI: 10.17487/RFC 1418

This memo addresses some concerns by defining a framework for running the SNMP in an environment which supports the OSI connectionless-mode transport service. [STANDARDS-TRACK]

RFC 1419 SNMP over AppleTalk

Authors: G. Minshall, M. Ritter.

Date: March 1993

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1419

This memo describes the method by which the Simple Network Management Protocol (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of the Internet UDP/IP protocol stack. [STANDARDS-TRACK]

RFC 1420 SNMP over IPX

Authors: S. Bostock.

Date: March 1993

Formats: txt html json

Obsoletes: RFC 1298

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1420

This document defines a convention for encapsulating Simple NetworkManagement Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2].

RFC 1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures

Authors: J. Linn.

Date: February 1993

Formats: txt html json

Obsoletes: RFC 1113

Status: HISTORIC

DOI: 10.17487/RFC 1421

This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK]

RFC 1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management

Authors: S. Kent.

Date: February 1993

Formats: txt json html

Obsoletes: RFC 1114

Status: HISTORIC

DOI: 10.17487/RFC 1422

This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]

RFC 1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers

Authors: D. Balenson.

Date: February 1993

Formats: txt json html

Obsoletes: RFC 1115

Status: HISTORIC

DOI: 10.17487/RFC 1423

This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail(PEM) in the Internet community. It is intended to become one member of the set of related PEM RFCs. This document is organized into four primary sections, dealing with message encryption algorithms, message integrity check algorithms, symmetric key management algorithms, and asymmetric key management algorithms (including both asymmetric encryption and asymmetric signature algorithms).
Some parts of this material are cited by other documents and it is anticipated that some of the material herein may be changed, added, or replaced without affecting the citing documents. Therefore, algorithm-specific material has been placed into this separate document.
Use of other algorithms and/or modes will require case-by-case study to determine applicability and constraints. The use of additional algorithms may be documented first in Prototype or Experimental RFCs.As experience is gained, these protocols may be considered for incorporation into the standard. Additional algorithms and modes approved for use in PEM in this context will be specified in successors to this document.

RFC 1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services

Authors: B. Kaliski.

Date: February 1993

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1424

This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK]

RFC 1425 SMTP Service Extensions

Authors: J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker.

Date: February 1993

Formats: txt html json

Obsoleted by: RFC 1651

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1425

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

RFC 1426 SMTP Service Extension for 8bit-MIMEtransport

Authors: J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker.

Date: February 1993

Formats: txt json html

Obsoleted by: RFC 1652

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1426

This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex

RFC 1427 SMTP Service Extension for Message Size Declaration

Authors: J. Klensin, N. Freed, Ed., K. Moore.

Date: February 1993

Formats: txt json html

Obsoleted by: RFC 1653

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1427

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

RFC 1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME

Authors: G. Vaudreuil.

Date: February 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1428

Protocols for extending SMTP to pass 8bit characters have been defined [3] [4]. These protocols require that messages transported by the extended SMTP are to be encoded in MIME [1] [2]. Before work began on these protocols, several SMTP implementations adopted ad-hoc mechanisms for sending 8bit data. It is desirable for the extendedSMTP environment and these ad hoc mechanisms interoperate. This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME.

RFC 1429 Listserv Distribute Protocol

Authors: E. Thomas.

Date: February 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1429

This memo specifies a subset of the distribution protocol used by theBITNET LISTSERV to deliver mail messages to large amounts of recipients. This protocol, known as DISTRIBUTE, optimizes the distribution by sending a single copy of the message over heavily loaded links, insofar as topological information is available to guide such decisions, and reduces the average turnaround time for large mailing lists to 5-15 minutes on the average. This memo describes a simple interface allowing non-BITNET mailing list exploders (or other bulk-delivery scripts) to take advantage of this service by letting the BITNET distribution network take care of the delivery.

RFC 1430 A Strategic Plan for Deploying an Internet X.500 Directory Service

Authors: S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby, S. Kent.

Date: February 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1430

There are a number of reasons why a new Internet Directory Service is required. This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 DirectoryService. It then describes in more detail the initial steps which need to be taken in order to achieve these goals, and how work already undertaken by Internet Engineering Task Force Working Groups(IETF WGs) is working towards these goals.

RFC 1431 DUA Metrics (OSI-DS 33 (v2))

Authors: P. Barker.

Date: February 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1431

This RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it.While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.
This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged. Particular issues covered include terminal requirements; style of interface; target user; default object classes and attribute types; use of DAP; error handling. The focus of the note is on"white pages" DUAs: this is a reflection of the current information base. Nevertheless much of the document will be applicable to DUAs developed for other types of Directory usage.
Please send comments to the author or to the discussion group <osi- ds@CS.UCL.AC.UK&rt;.

RFC 1432 Recent Internet Books

Authors: J. Quarterman.

Date: March 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1432

This article originally appeared in Volume 2 Number 12, (December1992) of Matrix News, the monthly newsletter of Matrix Information and Directory Services, Inc. (MIDS).

RFC 1433 Directed ARP

Authors: J. Garrett, J. Hagan, J. Wong.

Date: March 1993

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1433

A router with an interface to two IP networks via the same link level interface could observe that the two IP networks share the same link level network, and could advertise that information to hosts (viaICMP Redirects) and routers (via dynamic routing protocols).However, a host or router on only one of the IP networks could not use that information to communicate directly with hosts and routers on the other IP network unless it could resolve IP addresses on the"foreign" IP network to their corresponding link level addresses.Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses.

RFC 1434 Data Link Switching: Switch-to-Switch Protocol

Authors: R. Dixon, D. Kushi.

Date: March 1993

Formats: txt ps html json pdf

Obsoleted by: RFC 1795

Status: INFORMATIONAL

DOI: 10.17487/RFC 1434

This RFC describes IBM's support of Data Link Switching over TCP/IP.The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it.While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors.
Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: dlsw@ralvma.vnet.ibm.com.

RFC 1435 IESG Advice from Experience with Path MTU Discovery

Authors: S. Knowles.

Date: March 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1435

In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTUDiscovery.

RFC 1436 The Internet Gopher Protocol (a distributed document search and retrieval protocol)

Authors: F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, B. Albert.

Date: March 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1436

The Internet Gopher protocol is designed for distributed document search and retrieval. This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This document is adapted from the basic Internet Gopher protocol document first issued by the Microcomputer Center at the University ofMinnesota in 1991.

RFC 1437 The Extension of MIME Content-Types to a New Medium

Authors: N. Borenstein, M. Linimon.

Date: 1 April 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1437

A previous document, RFC 1341, defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the matter-transport/sentient-life-form type. The matter- transport/sentient-life-form MIME type is intended to facilitate the wider interoperation of electronic mail messages that include entire sentient life forms, such as human beings.
Other informally proposed subtypes, such as "non-sentient-life-form","non-sentient-non-life-form", and the orthogonally necessary but nevertheless puzzling "sentient-non-life-form", are not described in this memo.

RFC 1438 Internet Engineering Task Force Statements Of Boredom (SOBs)

Authors: A. Lyman Chapin, C. Huitema.

Date: 1 April 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1438

This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1439 The Uniqueness of Unique Identifiers

Authors: C. Finseth.

Date: March 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1439

This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people.

RFC 1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer

Authors: R. Troth.

Date: July 1993

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1440

This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community.

RFC 1441 Introduction to version 2 of the Internet-standard Network Management Framework

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: April 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1441

The purpose of this document is to provide an overview of version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2). [STANDARDS-TRACK]

RFC 1442 Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: April 1993

Formats: txt html json

Obsoleted by: RFC 1902

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1442

Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK]

RFC 1443 Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: April 1993

Formats: txt html json

Obsoleted by: RFC 1903

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1443

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

RFC 1444 Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: April 1993

Formats: txt json html

Obsoleted by: RFC 1904

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1444

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

RFC 1445 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Galvin, K. McCloghrie.

Date: April 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1445

It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. [STANDARDS-TRACK]

RFC 1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Galvin, K. McCloghrie.

Date: April 1993

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1446

It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK]

RFC 1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: K. McCloghrie, J. Galvin.

Date: April 1993

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1447

The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies. It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. [STANDARDS-TRACK]

RFC 1448 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: April 1993

Formats: txt json html

Obsoleted by: RFC 1905

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1448

It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]

RFC 1449 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: April 1993

Formats: txt json html

Obsoleted by: RFC 1906

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1449

It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]

RFC 1450 Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: April 1993

Formats: txt json html

Obsoleted by: RFC 1907

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1450

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]

RFC 1451 Manager-to-Manager Management Information Base

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: April 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1451

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. [STANDARDS-TRACK]

RFC 1452 Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: April 1993

Formats: txt html json

Obsoleted by: RFC 1908

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1452

The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

RFC 1453 A Comment on Packet Video Remote Conferencing and the Transport/Network Layers

Authors: W. Chimiak.

Date: April 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1453

The new generation of multimedia applications demands new features and new mechanisms for proper performance. ATM technology has moved from concept to reality, delivering very high bandwidths and new capabilities to the data link layer user. In an effort to anticipate the high bandwidth-delay data link layer, Delta-t [Delta-t], NETBLT[RFC 988], and VMTP [RFC 1045] were developed. The excellent insights and mechanisms pioneered by the creators of these experimental Internet protocols were used in the design of XpressTransfer Protocol (XTP) [XTP92] with the goal of eventually delivering ATM bandwidths to a user process. This RFC is a vehicle to inform the Internet community about XTP as it benefits from pastInternet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind.

RFC 1454 Comparison of Proposals for Next Version of IP

Authors: T. Dixon.

Date: May 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1454

This is a slightly edited reprint of RARE Technical Report(RTC(93)004).
The following is a brief summary of the characteristics of the three main proposals for replacing the current Internet Protocol. It is not intended to be exhaustive or definitive (a brief bibliography at the end points to sources of more information), but to serve as input to the European discussions on these proposals, to be co-ordinated byRARE and RIPE. It should be recognised that the proposals are themselves "moving targets", and in so far as this paper is accurate at all, it reflects the position at the 25th IETF meeting inWashington, DC. Comments from Ross Callon and Paul Tsuchiya on the original draft have been incorporated. Note that for a time the term"IPv7" was use to mean the eventual next version of IP, but that the same term was closely associated with a particilar proposal, so the term "IPng" is now used to identify the eventual next generation ofIP.
The paper begins with a "generic" discussion of the mechanisms for solving problems and achieving particular goals, before discussing the proposals invidually.

RFC 1455 Physical Link Security Type of Service

Authors: D. Eastlake 3rd.

Date: May 1993

Formats: txt json html

Obsoleted by: RFC 2474

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1455

This RFC documents an experimental protocol providing a Type ofService (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type ofService in the Internet Protocol Suite. The new TOS requests the network to provide what protection it can against surreptitious observation by outside agents of traffic so labeled. The purpose is protection against traffic analysis and as an additional possible level of data confidentiality. This TOS is consistent with all other defined types of service for IP version 4 in that it is based on link level characteristics and will not provide any particular guaranteed level of service.

RFC 1456 Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification

Authors: Vietnamese Standardization Working Group.

Date: May 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1456

This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into7-bit US ASCII and in an 8-bit form. These conventions are widely used by the overseas Vietnamese who are on the Internet and are active in USENET. This document only provides information and specifies no level of standard.

RFC 1457 Security Label Framework for the Internet

Authors: R. Housley.

Date: May 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1457

This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1458 Requirements for Multicast Protocols

Authors: R. Braudes, S. Zabele.

Date: May 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1458

This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols. This memo provides information for the Internet community. It does not specify an Internet standard.

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 1460 Post Office Protocol - Version 3

Authors: M. Rose.

Date: June 1993

Formats: txt json html

Obsoletes: RFC 1225

Obsoleted by: RFC 1725

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1460

This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS- TRACK]

RFC 1461 SNMP MIB extension for Multiprotocol Interconnect over X.25

Authors: D. Throop.

Date: May 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1461

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 MultiprotocolInterconnect (including IP) traffic carried over X.25. The objects defined here, along with the objects in the "SNMP MIB extension for the Packet Layer of X.25"[8], "SNMP MIB extension for LAPB"[7], and the "Definitions of Managed Objects for RS-232-like Hardware Devices"[6], combine to allow management of the traffic over an X.25 protocol stack.

RFC 1462 FYI on "What is the Internet?"

Authors: E. Krol, E. Hoffman.

Date: May 1993

Formats: txt html json

Also: FYI 0020

Status: INFORMATIONAL

DOI: 10.17487/RFC 1462

This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the InternetEngineering Task Force (IETF). Containing a modified chapter from EdKrol's 1992 book, "The Whole Internet User's Guide and Catalog," the paper covers the Internet's definition, history, administration, protocols, financing, and current issues such as growth, commercialization, and privatization.

RFC 1463 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings

Authors: E. Hoffman, L. Jackson.

Date: May 1993

Formats: txt html json

Also: FYI 0019

Status: INFORMATIONAL

DOI: 10.17487/RFC 1463

This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history.This FYI RFC includes references to free sources of information available on-line as well as traditional publications. A short section at the end includes information for accessing the on-line files. This FYI is intentionally brief so it can be easily used as a handout by user services personnel.

RFC 1464 Using the Domain Name System To Store Arbitrary String Attributes

Authors: R. Rosenbaum.

Date: May 1993

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1464

While the Domain Name System (DNS) [2,3] is generally used to store predefined types of information (e.g., addresses of hosts), it is possible to use it to store information that has not been previously classified.
This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. It uses DNS TXT resource records to store the information. It requires no change to current DNS implementations.

RFC 1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing

Authors: D. Eppenberger.

Date: May 1993

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1465

This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. This memo defines an Experimental Protocol for the Internet community.

RFC 1466 Guidelines for Management of IP Address Space

Authors: E. Gerich.

Date: May 1993

Formats: txt html json

Obsoletes: RFC 1366

Obsoleted by: RFC 2050

Status: INFORMATIONAL

DOI: 10.17487/RFC 1466

This document has been reviewed by the Federal Engineering PlanningGroup (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the Intercontinental Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space.

RFC 1467 Status of CIDR Deployment in the Internet

Authors: C. Topolcic.

Date: August 1993

Formats: txt html json

Obsoletes: RFC 1367

Status: HISTORIC

DOI: 10.17487/RFC 1467

This document describes the current status of the development and deployment of CIDR technology into the Internet. This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation.Since all the milestones proposed in RFC 1367 except for the delivery and installation of CIDR software were met, it does not seem appropriate to issue an updated schedule. Rather, this document is intended to provide information about how this effort is proceeding, which may be of interest to the community.

RFC 1468 Japanese Character Encoding for Internet Messages

Authors: J. Murai, M. Crispin, E. van der Poel.

Date: June 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1468

This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1469 IP Multicast over Token-Ring Local Area Networks

Authors: T. Pusateri.

Date: June 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1469

This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. Although an interim solution has emerged and is currently being used, it is the intention of this document to specify a more efficient means of transmission using an assigned Token-Ring functional address.

RFC 1470 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices

Authors: R. Enger, J. Reynolds.

Date: June 1993

Formats: txt json html

Obsoletes: RFC 1147

Also: FYI 0002

Status: INFORMATIONAL

DOI: 10.17487/RFC 1470

The goal of this FYI memo is to provide an update to FYI 2, RFC 1147[1], which provided practical information to site administrators and network managers. New and/or updated tools are listed in this RFC.Additonal descriptions are welcome, and should be sent to: noctools- entries@merit.edu.

RFC 1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol

Authors: F. Kastenholz.

Date: June 1993

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1471

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 describes managed objects used for managing theLink Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10,11, & 12].

RFC 1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol

Authors: F. Kastenholz.

Date: June 1993

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1472

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 describes managed objects used for managing theSecurity Protocols on subnetwork interfaces using the family ofPoint-to-Point Protocols [8, 9, 10, 11, & 12].

RFC 1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol

Authors: F. Kastenholz.

Date: June 1993

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1473

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 describes managed objects used for managing the IPNetwork Control Protocol on subnetwork interfaces using the family ofPoint-to-Point Protocols [8, 9, 10, 11, & 12].

RFC 1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol

Authors: F. Kastenholz.

Date: June 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1474

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 describes managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols.

RFC 1475 TP/IX: The Next Internet

Authors: R. Ullmann.

Date: June 1993

Formats: txt json html

Obsoleted by: RFC 6814

Status: HISTORIC

DOI: 10.17487/RFC 1475

The first version of this memo, describing a possible next generation of Internet protocols, was written by the present author in the summer and fall of 1989, and circulated informally, including to theIESG, in December 1989. A further informal note on the addressing, called "Toasternet Part II", was circulated on the IETF mail list during March of 1992.

RFC 1476 RAP: Internet Route Access Protocol

Authors: R. Ullmann.

Date: June 1993

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1476

This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider.

RFC 1477 IDPR as a Proposed Standard

Authors: M. Steenstrup.

Date: July 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1477

This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1478 An Architecture for Inter-Domain Policy Routing

Authors: M. Steenstrup.

Date: June 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1478

We present an architecture for inter-domain policy routing (IDPR).The objective of IDPR is to construct and maintain routes, between source and destination administrative domains, that provide user traffic with the requested services within the constraints stipulated for the domains transited. The IDPR architecture is designed to accommodate an internetwork containing tens of thousands of administrative domains with heterogeneous service requirements and restrictions.

RFC 1479 Inter-Domain Policy Routing Protocol Specification: Version 1

Authors: M. Steenstrup.

Date: July 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1479

We present the set of protocols and procedures that constituteInter-Domain Policy Routing (IDPR). IDPR includes the virtual gateway protocol, the flooding protocol, the route server query protocol, the route generation procedure, the path control protocol, and the data message forwarding procedure.

RFC 1480 The US Domain

Authors: A. Cooper, J. Postel.

Date: June 1993

Formats: txt json html

Obsoletes: RFC 1386

Status: INFORMATIONAL

DOI: 10.17487/RFC 1480

This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1481 IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling

Authors: C. Huitema.

Date: July 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1481

CIDR is proposed as an immediate term strategy to extend the life of the current 32 bit IP address space. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1482 Aggregation Support in the NSFNET Policy-Based Routing Database

Authors: M. Knopper, S. Richardson.

Date: June 1993

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1482

This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing(CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone NetworkService. Mechanisms for exchange of route aggregates between the backbone service and regional/midlevel networks are specified.Additionally, the memo proposes the implementation of an AggregateRegistry which can be used by network service providers to share information about the use of aggregation. Finally, the operational impact of incorporating CIDR and aggregation is considered, including an analysis of how routing table size will be affected. This impact analysis will be used to modify the deployment plan, if necessary, to maximize operational stability.

RFC 1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5

Authors: J. Heinanen.

Date: July 1993

Formats: txt html json

Obsoleted by: RFC 2684

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1483

This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. The first method allows multiplexing of multiple protocols over a single ATM virtual circuit whereas the second method assumes that each protocol is carried over a separate ATM virtual circuit.

RFC 1484 Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2))

Authors: S. Hardcastle-Kille.

Date: July 1993

Formats: txt json html

Obsoleted by: RFC 1781, RFC 3494

Status: HISTORIC

DOI: 10.17487/RFC 1484

The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability
This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a format for representing names, and to procedures to resolve them. This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in [HK93], and it is intended that these specifications are compatible. Please send comments to the author or to the discussion group: <osi-ds@CS.UCL.AC.UK&rt;.

RFC 1485 A String Representation of Distinguished Names (OSI-DS 23 (v5))

Authors: S. Hardcastle-Kille.

Date: July 1993

Formats: txt json html

Obsoleted by: RFC 1779, RFC 3494

Status: HISTORIC

DOI: 10.17487/RFC 1485

The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1.When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. Please send comments to the author or to the discussion group <osi-ds@CS.UCL.AC.UK&rt;.

RFC 1486 An Experiment in Remote Printing

Authors: M. Rose, C. Malamud.

Date: July 1993

Formats: txt html json

Obsoleted by: RFC 1528, RFC 1529

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1486

This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC 1487 X.500 Lightweight Directory Access Protocol

Authors: W. Yeong, T. Howes, S. Kille.

Date: July 1993

Formats: txt html json

Obsoleted by: RFC 1777, RFC 3494

Status: HISTORIC

DOI: 10.17487/RFC 1487

The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of theDirectory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the Directory, and is intended to be a complement to the DAP itself.
Key aspects of LDAP are:
- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.
- Many protocol data elements are encoding as ordinary strings (e.g.,Distinguished Names).
- A lightweight BER encoding is used to encode all protocol elements.

RFC 1488 The X.500 String Representation of Standard Attribute Syntaxes

Authors: T. Howes, S. Kille, W. Yeong, C. Robbins.

Date: July 1993

Formats: txt json html

Obsoleted by: RFC 1778

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1488

The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3].

RFC 1489 Registration of a Cyrillic Character Set

Authors: A. Chernov.

Date: July 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1489

Though the proposed character set "koi8-r" is not currently an international standard, there is very large user community (including Relcom Net) supporting it. Factually, "koi8-r" is de-facto standard for Unix and global network applications in the former Soviet Union. This is the reason the Society of Unix User Groups (SUUG) believes "koi8-r" should be registered. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1490 Multiprotocol Interconnect over Frame Relay

Authors: T. Bradley, C. Brown, A. Malis.

Date: July 1993

Formats: txt json html

Obsoletes: RFC 1294

Obsoleted by: RFC 2427

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1490

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU.
Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use.

RFC 1491 A Survey of Advanced Usages of X.500

Authors: C. Weider, R. Wright.

Date: July 1993

Formats: txt json html

Also: FYI 0021

Status: INFORMATIONAL

DOI: 10.17487/RFC 1491

This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a "White Pages" service. This RFC is a product of the IntegratedDirectory Services Working Group of the Application and User ServicesAreas of the IETF.

RFC 1492 An Access Control Protocol, Sometimes Called TACACS

Authors: C. Finseth.

Date: July 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1492

This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1493 Definitions of Managed Objects for Bridges

Authors: E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie.

Date: July 1993

Formats: txt html json

Obsoletes: RFC 1286

Obsoleted by: RFC 4188

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1493

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging.Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.

RFC 1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies

Authors: H. Alvestrand, S. Thompson.

Date: August 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1494

This document describes the content of the "IANA MHS/MIME Equivalence table", and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. [STANDARDS-TRACK]

RFC 1495 Mapping between X.400 and RFC-822 Message Bodies

Authors: H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson.

Date: August 1993

Formats: txt json html

Obsoleted by: RFC 2156

Updates: RFC 1327

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1495

Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK]

RFC 1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages

Authors: H. Alvestrand, J. Romaguera, K. Jordan.

Date: August 1993

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1496

This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT obsoleted. [STANDARDS-TRACK]

RFC 1497 BOOTP Vendor Information Extensions

Authors: J. Reynolds.

Date: August 1993

Formats: txt html json

Obsoletes: RFC 1395, RFC 1084, RFC 1048

Obsoleted by: RFC 1533

Updates: RFC 0951

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1497

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP).

RFC 1498 On the Naming and Binding of Network Destinations

Authors: J. Saltzer.

Date: August 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1498

This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas:First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. To illustrate the usefulness of this approach, the paper interprets some more subtle and confusing properties of two real-world network systems for naming destinations.

RFC 1499 Summary of 1400-1499

Authors: J. Elliott.

Date: January 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1499

RFC 1500 Internet Official Protocol Standards

Authors: J. Postel.

Date: August 1993

Formats: txt json html

Obsoletes: RFC 1410

Obsoleted by: RFC 1540

Status: HISTORIC

DOI: 10.17487/RFC 1500

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]

RFC 1501 OS/2 User Group

Authors: E. Brunsen.

Date: August 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1501

Memo soliciting reactions to the proposal of a OS/2 User Group. This memo provides information for the Internet community. This memo does not specify an IAB standard of any kind.

RFC 1502 X.400 Use of Extended Character Sets

Authors: H. Alvestrand.

Date: August 1993

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1502

This RFC defines a suggested method of using "GeneralText" in order to harmonize as much as possible the usage of this body part. [STANDARDS- TRACK]

RFC 1503 Algorithms for Automating Administration in SNMPv2 Managers

Authors: K. McCloghrie, M. Rose.

Date: August 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1503

When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing

Authors: A. Oppenheimer.

Date: August 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1504

This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1505 Encoding Header Field for Internet Messages

Authors: A. Costanzo, D. Robinson, R. Ullmann.

Date: August 1993

Formats: txt json html

Obsoletes: RFC 1154

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1505

This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154 [1].

RFC 1506 A Tutorial on Gatewaying between X.400 and Internet Mail

Authors: J. Houttuin.

Date: August 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1506

This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1507 DASS - Distributed Authentication Security Service

Authors: C. Kaufman.

Date: September 1993

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1507

The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC 1508 Generic Security Service Application Program Interface

Authors: J. Linn.

Date: September 1993

Formats: txt json html

Obsoleted by: RFC 2078

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1508

This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification definesGSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms

RFC 1509 Generic Security Service API : C-bindings

Authors: J. Wray.

Date: September 1993

Formats: txt json html

Obsoleted by: RFC 2744

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1509

This document specifies C language bindings for the Generic SecurityService Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents.
The Generic Security Service Application Programming Interface (GSS-API) provides security services to its callers, and is intended for implementation atop alternative underlying cryptographic mechanisms.Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis.

RFC 1510 The Kerberos Network Authentication Service (V5)

Authors: J. Kohl, C. Neuman.

Date: September 1993

Formats: txt json html

Obsoleted by: RFC 4120, RFC 6649

Status: HISTORIC

DOI: 10.17487/RFC 1510

This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere [1,2], is presently in production use at MIT'sProject Athena, and at other Internet sites.

RFC 1511 Common Authentication Technology Overview

Authors: J. Linn.

Date: September 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1511

This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1512 FDDI Management Information Base

Authors: J. Case, A. Rijsinghani.

Date: September 1993

Formats: txt html json

Updates: RFC 1285

Status: HISTORIC

DOI: 10.17487/RFC 1512

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 based on the ANSI FDDI SMT 7.3 draft standard [8], which has been forwarded for publication by the X3T9.5 committee.

RFC 1513 Token Ring Extensions to the Remote Network Monitoring MIB

Authors: S. Waldbusser.

Date: September 1993

Formats: txt html json

Updates: RFC 1271

Status: HISTORIC

DOI: 10.17487/RFC 1513

This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks.
The Remote Network Monitoring MIB, RFC 1271, defines a framework for remote monitoring functions implemented on a network probe. That MIB defines objects broken down into nine functional groups. Some of those functional groups, the statistics and the history groups, have a view of the data-link layer that is specific to the media type and require specific objects to be defined for each media type. RFC 1271 defined those specific objects necessary for Ethernet. This companion memo defines those specific objects necessary for TokenRing LANs.
In addition, this memo defines some additional monitoring functions specifically for Token Ring. These are defined in the Ring StationGroup, the Ring Station Order Group, the Ring Station ConfigurationGroup, and the Source Routing Statistics Group.

RFC 1514 Host Resources MIB

Authors: P. Grillo, S. Waldbusser.

Date: September 1993

Formats: txt json html

Obsoleted by: RFC 2790

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1514

This memo defines a MIB for use with managing host systems. The term"host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services(e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix.

RFC 1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)

Authors: D. McMaster, K. McCloghrie, S. Roberts.

Date: September 1993

Formats: txt json html

Obsoleted by: RFC 3636

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1515

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3Medium Attachment Units (MAUs).

RFC 1516 Definitions of Managed Objects for IEEE 802.3 Repeater Devices

Authors: D. McMaster, K. McCloghrie.

Date: September 1993

Formats: txt html json

Obsoletes: RFC 1368

Obsoleted by: RFC 2108

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1516

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing IEEE 802.3 10Mb/second baseband repeaters, sometimes referred to as "hubs."

RFC 1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)

Authors: Internet Engineering Steering Group, R. Hinden.

Date: September 1993

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1517

Classless Inter-Domain Routing (CIDR) defines a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers. [STANDARDS-TRACK]

RFC 1518 An Architecture for IP Address Allocation with CIDR

Authors: Y. Rekhter, T. Li.

Date: September 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1518

This paper provides an architecture and a plan for allocating IP addresses in the Internet. This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. [STANDARDS-TRACK]

RFC 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy

Authors: V. Fuller, T. Li, J. Yu, K. Varadhan.

Date: September 1993

Formats: txt json html

Obsoletes: RFC 1338

Obsoleted by: RFC 4632

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1519

This memo discusses strategies for address assignment of the existingIP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers.

RFC 1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment

Authors: Y. Rekhter, C. Topolcic.

Date: September 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1520

The purpose of this document is twofold. First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not. Second, it addresses the implications of running CIDR- capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra- domain routing. This memo provides information for the Internet community. It does not specify an Internet standard.

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 1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text

Authors: K. Moore.

Date: September 1993

Formats: txt html json

Obsoletes: RFC 1342

Obsoleted by: RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1522

This memo describes an extension to the message format defined in RFC1521 [1], to allow the representation of character sets other thanASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521.

RFC 1523 The text/enriched MIME Content-type

Authors: N. Borenstein.

Date: September 1993

Formats: txt html json

Obsoleted by: RFC 1563, RFC 1896

Status: INFORMATIONAL

DOI: 10.17487/RFC 1523

MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms.

RFC 1524 A User Agent Configuration Mechanism For Multimedia Mail Format Information

Authors: N. Borenstein.

Date: September 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1524

This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. The mechanism is explicitly designed to work with mail systems based Internet mail as defined byRFC's 821 (STD 10), 822 (STD 11), 934, 1049 (STD 11), 1113, and theMultipurpose Internet Mail Extensions, known as MIME. However, with some extensions it could probably be made to work for X.400-based mail systems as well. The format and mechanism are proposed in a manner that is generally operating-system independent. However, certain implementation details will inevitably reflect operating system differences, some of which will have to be handled in a uniform manner for each operating system. This memo makes such situations explicit, and, in an appendix, suggests a standard behavior under the UNIX operating system.

RFC 1525 Definitions of Managed Objects for Source Routing Bridges

Authors: E. Decker, K. McCloghrie, P. Langille, A. Rijsinghani.

Date: September 1993

Formats: txt json html

Obsoletes: RFC 1286

Status: HISTORIC

DOI: 10.17487/RFC 1525

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 source routing and source routing transparent bridges. These bridges are also required to implement relevant groups in the Bridge MIB. [STANDARDS-TRACK]

RFC 1526 Assignment of System Identifiers for TUBA/CLNP Hosts

Authors: D. Piscitello.

Date: September 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1526

This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. The mechanism is extensible and can provide a basis for assigning system identifiers in a globally unique fashion.

RFC 1527 What Should We Plan Given the Dilemma of the Network?

Authors: G. Cook.

Date: September 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1527

Early last year, as the concluding effort of an 18 month appointment at the US Congress Office of Technology Assessment (OTA), I drafted a potential policy framework for Congressional action on the NationalResearch and Education Network (NREN).
The Internet community needs to be asking what the most important policy issues facing the network are. And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow forCongress to make?
It is unfortunate that this was never officially done for or by theCongress by OTA. What we have as a result is network policy making being carried out now by the Science Subcommittee on the House side in consultation with a relatively small group of interested parties.The debate seems to be more focused on preserving turf than on any sweeping understanding of what the legislation is doing. That is unfortunate.
In the hope that it may contain some useful ideas, I offer a shortened version of the suggested policy draft as information for the Internet community.

RFC 1528 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures

Authors: C. Malamud, M. Rose.

Date: October 1993

Formats: txt json html

Obsoletes: RFC 1486

Obsoleted by: RFC 9121

Status: HISTORIC

DOI: 10.17487/RFC 1528

This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC 1529 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies

Authors: C. Malamud, M. Rose.

Date: October 1993

Formats: txt json html

Obsoletes: RFC 1486

Status: INFORMATIONAL

DOI: 10.17487/RFC 1529

This document defines the administrative policies for the operation of remote printer facilities within the context of the tpc.int subdomain. The document describes different approaches to resource recovery for remote printer server sites and includes discussions of issues pertaining to auditing, security, and denial of access. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC 1530 Principles of Operation for the TPC.INT Subdomain: General Principles and Policy

Authors: C. Malamud, M. Rose.

Date: October 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1530

This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System [1,2].
This document is informational and applies only to those Internet sites that choose to register themselves within the tpc.int subdomain. The tpc.int subdomain is organized as a cooperative of the sites that provide access within the context of the subdomain.Policy for the subdomain is set by a board responsible to the cooperative.
The primary purpose of the tpc.int subdomain is to provide transparent mapping between general-purpose computers on the Internet and special-purpose devices directly connected to the telephone network. Initially, a remote printing service is defined [3,4] which ties together G3-compatible facsimile devices on the telephone network with users of electronic mail in the Internet and associated message-handling domains connected to the Internet by application- layer gateways.
It should be noted that remote printer gateways have long been technically feasible and have become an integral part of many individual networks. The tpc.int subdomain integrates individual sites into a common namespace, transforming remote printing from a single-site, value-added service into an integral transparent service in the global Internet.

RFC 1531 Dynamic Host Configuration Protocol

Authors: R. Droms.

Date: October 1993

Formats: txt json html

Obsoleted by: RFC 1541

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1531

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9].

RFC 1532 Clarifications and Extensions for the Bootstrap Protocol

Authors: W. Wimer.

Date: October 1993

Formats: txt html json

Obsoleted by: RFC 1542

Updates: RFC 0951

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1532

Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas.
In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these.

RFC 1533 DHCP Options and BOOTP Vendor Extensions

Authors: S. Alexander, R. Droms.

Date: October 1993

Formats: txt html json

Obsoletes: RFC 1497, RFC 1395, RFC 1084, RFC 1048

Obsoleted by: RFC 2132

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1533

The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the "options" field of the DHCP message. The data items themselves are also called"options."
This document specifies the current set of DHCP options. This document will be periodically updated as new options are defined.Each superseding document will include the entire current list of valid options.
All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of theDHCP options defined in this document, except for those specific toDHCP as defined in section 9, may be used as BOOTP vendor information extensions.

RFC 1534 Interoperation Between DHCP and BOOTP

Authors: R. Droms.

Date: October 1993

Formats: txt json html

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1534

DHCP provides a superset of the functions provided by BOOTP. This document describes the interactions between DHCP and BOOTP network participants.

RFC 1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software

Authors: E. Gavron.

Date: October 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1535

This document discusses a flaw in some of the currently distributed name resolver clients. The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit (although not by the masses). This document points out the flaw, a case in point, and a solution.

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 1537 Common DNS Data File Configuration Errors

Authors: P. Beertema.

Date: October 1993

Formats: txt html json

Obsoleted by: RFC 1912

Status: INFORMATIONAL

DOI: 10.17487/RFC 1537

This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time.

RFC 1538 Advanced SNA/IP : A Simple SNA Transport Protocol

Authors: W. Behl, B. Sterling, W. Teskey.

Date: October 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1538

This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors. Any questions or comments relative to the contents of this RFC may be sent to the followingInternet address: snaip@mcdata.com.

RFC 1539 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force

Authors: G. Malkin.

Date: October 1993

Formats: txt json html

Obsoletes: RFC 1391

Obsoleted by: RFC 1718

Status: INFORMATIONAL

DOI: 10.17487/RFC 1539

Over the last two years, the attendance at Internet Engineering TaskForce (IETF) Plenary meetings has grown phenomenally. Approximately38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.

RFC 1540 Internet Official Protocol Standards

Authors: J. Postel.

Date: October 1993

Formats: txt html json

Obsoletes: RFC 1500

Obsoleted by: RFC 1600

Status: HISTORIC

DOI: 10.17487/RFC 1540

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]

RFC 1541 Dynamic Host Configuration Protocol

Authors: R. Droms.

Date: October 1993

Formats: txt html json

Obsoletes: RFC 1531

Obsoleted by: RFC 2131

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1541

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9]. Due to some errors introduced into RFC1531 in the editorial process, this memo is reissued as RFC 1541.

RFC 1542 Clarifications and Extensions for the Bootstrap Protocol

Authors: W. Wimer.

Date: October 1993

Formats: txt json html

Obsoletes: RFC 1532

Updates: RFC 0951

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1542

Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. Due to some errors introduced into RFC 1532 in the editorial process, this memo is reissued as RFC 1542.
In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these.

RFC 1543 Instructions to RFC Authors

Authors: J. Postel.

Date: October 1993

Formats: txt json html

Obsoletes: RFC 1111, RFC 0825

Obsoleted by: RFC 2223

Status: INFORMATIONAL

DOI: 10.17487/RFC 1543

This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1544 The Content-MD5 Header Field

Authors: M. Rose.

Date: November 1993

Formats: txt html json

Obsoleted by: RFC 1864

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1544

This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages.

RFC 1545 FTP Operation Over Big Address Records (FOOBAR)

Authors: D. Piscitello.

Date: November 1993

Formats: txt html json

Obsoleted by: RFC 1639

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1545

This paper describes a convention for specifying longer addresses in the PORT command.

RFC 1546 Host Anycasting Service

Authors: C. Partridge, T. Mendez, W. Milliken.

Date: November 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1546

This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. Insofar as is possible, this memo tries to be agnostic about how the service is actually provided by the internetwork. This memo describes an experimental service and does not propose a protocol. This memo is produced by the Internet Research Task Force (IRTF).

RFC 1547 Requirements for an Internet Standard Point-to-Point Protocol

Authors: D. Perkins.

Date: December 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1547

This document discusses the evaluation criteria for an InternetStandard Data Link Layer protocol to be used with point-to-point links. Although many industry standard protocols and ad hoc protocols already exist for the data link layer, none are both complete and sufficiently versatile to be accepted as an InternetStandard. In preparation to designing such a protocol, the features necessary to qualify a point-to-point protocol as an InternetStandard are discussed in detail. An analysis of the strengths and weaknesses of several existing protocols on the basis of these requirements demonstrates the failure of each to address key issues.
Historical Note: This was the design requirements document datedJune 1989, which was followed for RFC-1134 through the present.It is now published for completeness and future guidance.

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 1549 PPP in HDLC Framing

Authors: W. Simpson, Ed..

Date: December 1993

Formats: txt html json

Obsoleted by: RFC 1662

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1549

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of HDLC for framing PPP encapsulated packets. This document is the product of the Point-to-Point ProtocolWorking Group of the Internet Engineering Task Force (IETF).Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.

RFC 1550 IP: Next Generation (IPng) White Paper Solicitation

Authors: S. Bradner, A. Mankin.

Date: December 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1550

This memo solicits white papers on topics related to the IPng requirements and selection criteria. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1551 Novell IPX Over Various WAN Media (IPXWAN)

Authors: M. Allen.

Date: December 1993

Formats: txt html json

Obsoleted by: RFC 1634

Status: INFORMATIONAL

DOI: 10.17487/RFC 1551

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and adds capability forUnnumbered RIP links, On-demand statically routed links and client to router connectivity.

RFC 1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP)

Authors: W. Simpson.

Date: December 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1552

The Point-to-Point Protocol (PPP) [1] provides a method for transmitting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
The IPX protocol was originally used in Novell's NetWare products[3], and is now supported by numerous other vendors. This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP.
This memo is the product of the Point-to-Point Protocol Working Group of the IETF. Comments should be submitted to the ietf- ppp@ucdavis.edu mailing list.

RFC 1553 Compressing IPX Headers Over WAN Media (CIPX)

Authors: S. Mathur, M. Lewis.

Date: December 1993

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1553

This document describes a method for compressing the headers of IPX datagrams (CIPX). With this method, it is possible to significantly improve performance over lower speed wide area network (WAN) media. For normal IPX packet traffic, CIPX can provide a compression ratio of approximately 2:1 including both IPX header and data. This method can be used on various type of WAN media, including those supporting PPP and X.25.
This memo ia a product of the Point-to-Point Protocol Extensions(PPPEXT) Working Group of the IETF. Comments should be sent to the authors and the ietf-ppp@ucdavis.edu mailing list.

RFC 1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP

Authors: M. Ohta, K. Handa.

Date: December 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1554

This memo describes a text encoding scheme: "ISO-2022-JP-2", which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. The encoding is a multilingual extension of "ISO-2022-JP", the existing encoding for Japanese [2022JP]. The encoding is supported by an Emacs based multilingual text editor: MULE [MULE]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1555 Hebrew Character Encoding for Internet Messages

Authors: H. Nussbacher, Y. Bourvine.

Date: December 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1555

This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME[RFC1521] and ISO-8859-8.

RFC 1556 Handling of Bi-directional Texts in MIME

Authors: H. Nussbacher.

Date: December 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1556

This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME.

RFC 1557 Korean Character Encoding for Internet Messages

Authors: U. Choi, K. Chon, H. Park.

Date: December 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1557

This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822]. This encoding method was specified in 1991, and has since then been used. It has now widely being used in Korean IP networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1558 A String Representation of LDAP Search Filters

Authors: T. Howes.

Date: December 1993

Formats: txt html json

Obsoleted by: RFC 1960

Status: INFORMATIONAL

DOI: 10.17487/RFC 1558

The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters.

RFC 1559 DECnet Phase IV MIB Extensions

Authors: J. Saperia.

Date: December 1993

Formats: txt html json

Obsoletes: RFC 1289

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1559

This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. It reflects changes which are the result of operational experience based on RFC 1289. [STANDARDS-TRACK]

RFC 1560 The MultiProtocol Internet

Authors: B. Leiner, Y. Rekhter.

Date: December 1993

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1560

This document was prepared by the authors on behalf of the InternetArchitecture Board (IAB). It is offered by the IAB to stimulate discussion.
There has recently been considerable discussion on two topics:MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue.
In particular, it recommends that the IETF/IESG/IAB should continue to be a force for consensus on a single protocol suite and internet layer protocol. The IETF/IESG/IAB should:
- maintain its focus on the TCP/IP protocol suite,
- work to select a single next-generation internet protocol and develop mechanisms to aid in transition from the current IPv4, and
- continue to explore mechanisms to interoperate and share resources with other protocol suites within the Internet.

RFC 1561 Use of ISO CLNP in TUBA Environments

Authors: D. Piscitello.

Date: December 1993

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1561

This memo specifies a profile of the ISO/IEC 8473 Connectionless-modeNetwork Layer Protocol (CLNP, [1]) for use in conjunction with RFC1347, TCP/UDP over Bigger Addresses (TUBA, [2]). It describes the use of CLNP to provide the lower-level service expected byTransmission Control Protocol (TCP, [3]) and User Datagram Protocol(UDP, [4]). CLNP provides essentially the same datagram service asInternet Protocol (IP, [5]), but offers a means of conveying bigger network addresses (with additional structure, to aid routing).
While the protocols offer nearly the same services, IP and CLNP are not identical. This document describes a means of preserving the semantics of IP information that is absent from CLNP while preserving consistency between the use of CLNP in Internet and OSI environments.This maximizes the use of already-deployed CLNP implementations.

RFC 1562 Naming Guidelines for the AARNet X.500 Directory Service

Authors: G. Michaelson, M. Prior.

Date: December 1993

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1562

AARNet is a member network of the global Internet and participates in the global Internet X.500 based Directory Service. A number of RFC's have been issued that make recommendations that alter or supplement the OSI/ETU standards for X.500 [1]. In general, these RFCs will be followed by the AARNet Directory Service. However, in certain cases we wish to align ourselves with our national ISO body (StandardsAustralia) rather than the Internet where they conflict. In naming, we have chosen to align ourselves with Standards Australia and this document notes the difference in our approach to the Internet guidelines suggested in RFC 1384 [2].

RFC 1563 The text/enriched MIME Content-type

Authors: N. Borenstein.

Date: January 1994

Formats: txt json ps pdf html

Obsoletes: RFC 1523

Obsoleted by: RFC 1896

Status: INFORMATIONAL

DOI: 10.17487/RFC 1563

MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms.

RFC 1564 DSA Metrics (OSI-DS 34 (v3))

Authors: P. Barker, R. Hedberg.

Date: January 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1564

This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. The intention is that the replies to the questions posed provide a fairly full description of a DSA. Some of the questions will yield answers which are purely descriptive; others, however, are intended to elicit answers which give some measure of the utility of the DSA. The marks awarded for a DSA in each particular area should give a good indication of the DSA's capabilities, and its suitability for particular uses.
Please send comments to the authors or to the discussion group<osi-ds@CS.UCL.AC.UK&rt;.

RFC 1565 Network Services Monitoring MIB

Authors: S. Kille, N. Freed.

Date: January 1994

Formats: txt html json

Obsoleted by: RFC 2248

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1565

This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK]

RFC 1566 Mail Monitoring MIB

Authors: S. Kille, N. Freed.

Date: January 1994

Formats: txt json html

Obsoleted by: RFC 2249, RFC 2789

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1566

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK]

RFC 1567 X.500 Directory Monitoring MIB

Authors: G. Mansfield, S. Kille.

Date: January 1994

Formats: txt json html

Obsoleted by: RFC 2605

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1567

This document defines a portion of the Management Information Base(MIB). It defines the MIB for monitoring Directory System Agents(DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs.

RFC 1568 Simple Network Paging Protocol - Version 1(b)

Authors: A. Gwinn.

Date: January 1994

Formats: txt html json

Obsoleted by: RFC 1645

Status: INFORMATIONAL

DOI: 10.17487/RFC 1568

This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months in one nationwide paging firm. One other paging firm is in the process of adopting it.
Earlier versions of this specification were reviewed by IESG members and the IETF's "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETFWork", below.

RFC 1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures

Authors: M. Rose.

Date: January 1994

Formats: txt html json

Obsoleted by: RFC 1703

Status: INFORMATIONAL

DOI: 10.17487/RFC 1569

This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 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 1571 Telnet Environment Option Interoperability Issues

Authors: D. Borman.

Date: January 1994

Formats: txt html json

Updates: RFC 1408

Status: INFORMATIONAL

DOI: 10.17487/RFC 1571

This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1572 Telnet Environment Option

Authors: S. Alexander, Ed..

Date: January 1994

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1572

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.
This document corrects some errors in [1].

RFC 1573 Evolution of the Interfaces Group of MIB-II

Authors: K. McCloghrie, F. Kastenholz.

Date: January 1994

Formats: txt json html

Obsoletes: RFC 1229

Obsoleted by: RFC 2233

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1573

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANARDS-TRACK]

RFC 1574 Essential Tools for the OSI Internet

Authors: S. Hares, C. Wittbrodt.

Date: February 1994

Formats: txt html json

Obsoletes: RFC 1139

Status: INFORMATIONAL

DOI: 10.17487/RFC 1574

This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473(CLNP):
- ping or OSI Echo function- traceroute function which uses the OSI Echo function- routing table dump function
These CLNS tools are the basics required for hosts and routers forCLNS network support. It is intended that this document specify the most basic support level required for CLNS hosts and routers.
To support some of the needed tools (ping and traceroute) this memo specifies the mechanism specified in RFC 1575 [3].

RFC 1575 An Echo Function for CLNP (ISO 8473)

Authors: S. Hares, C. Wittbrodt.

Date: February 1994

Formats: txt html json

Obsoletes: RFC 1139

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1575

This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of anEcho function to ISO 8473" an integral part of Version 2 of ISO 8473.

RFC 1576 TN3270 Current Practices

Authors: J. Penner.

Date: January 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1576

This document describes the existing implementation of transferring3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270.
Information is provided to aid in the implementation of TN3270 servers as well as client terminal emulators.
The following areas pertaining to TN3270 implementations are covered in this document:
1. the telnet options negotiated to transition from a NVT ASCII state to a TN3270 state ready to process incoming 3270 data stream commands
2. the method for sending and receiving 3270 data
3. the method of handling some special keys known as SYSREQ andATTN using current available telnet commands
4. the events that will transition a TN3270 session back to an NVT session

RFC 1577 Classical IP and ARP over ATM

Authors: M. Laubach.

Date: January 1994

Formats: txt json html

Obsoleted by: RFC 2225

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1577

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 3. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connectingIP end-stations ("members") and routers operating in the "classical"LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper.
This memo introduces general ATM technology and nomenclature.Readers are encouraged to review the ATM Forum and ITU-TS (formerlyCCITT) references for more detailed information about ATM implementation agreements and standards.

RFC 1578 FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions

Authors: J. Sellers.

Date: February 1994

Formats: txt html json

Obsoleted by: RFC 1941

Status: INFORMATIONAL

DOI: 10.17487/RFC 1578

The goal of this FYI RFC, produced by the Internet School Networking(ISN) group in the User Services Area of the Internet EngineeringTask Force (IETF), is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. It is directed at educators, school media specialists, and school administrators who are recently connected to the Internet, who are accessing the Internet via dial-up or another means which is not a direct connection, or who are considering an Internet connection as a resource for their schools.

RFC 1579 Firewall-Friendly FTP

Authors: S. Bellovin.

Date: February 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1579

This memo describes a suggested change to the behavior of FTP client programs. No protocol modifications are required, though we outline some that might be useful.

RFC 1580 Guide to Network Resource Tools

Authors: EARN Staff.

Date: March 1994

Formats: txt html json

Also: FYI 0023

Status: INFORMATIONAL

DOI: 10.17487/RFC 1580

The purpose of this guide is to supply the basic information that anyone on the network needs to try out and begin using tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 23]

RFC 1581 Protocol Analysis for Extensions to RIP to Support Demand Circuits

Authors: G. Meyer.

Date: February 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1581

As required by Routing Protocol Criteria [1], this report documents the key features of Routing over Demand Circuits on Wide AreaNetworks - RIP [2] and the current implementation experience.

RFC 1582 Extensions to RIP to Support Demand Circuits

Authors: G. Meyer.

Date: February 1994

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1582

Running routing protocols on connection oriented Public DataNetworks, for example X.25 packet switched networks or ISDN, can be expensive if the standard form of periodic broadcasting of routing information is adhered to. The high cost arises because a connection has to all practical intents and purposes be kept open to every destination to which routing information is to be sent, whether or not it is being used to carry user data.
Routing information may also fail to be propagated if the number of destinations to which the routing information is to be sent exceeds the number of channels available to the router on the Wide AreaNetwork (WAN).
This memo defines a generalized modification which can be applied toBellman-Ford (or distance vector) algorithm information broadcasting protocols, for example IP RIP, Netware RIP or Netware SAP, which overcomes the limitations of the traditional methods described above.
The routing protocols support a purely triggered update mechanism on demand circuits on WANs. The protocols run UNMODIFIED on LANs or fixed point-to-point links.
Routing information is sent on the WAN when the routing database is modified by new routing information received from another interface.When this happens a (triggered) update is sent to a list of destinations on other WAN interfaces. Because routing protocols are datagram based they are not guaranteed to be received by the peer router on the WAN. An acknowledgement and retransmission mechanism is provided to ensure that routing updates are received.
The WAN circuit manager advises the routing applications on the reachability and non-reachability of destinations on the WAN.

RFC 1583 OSPF Version 2

Authors: J. Moy.

Date: March 1994

Formats: txt pdf json ps html

Obsoletes: RFC 1247

Obsoleted by: RFC 2178

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1583

This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree.
OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. Separate routes can be calculated for each IP Type of Service. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.
OSPF Version 2 was originally documented in RFC 1247. The differences between RFC 1247 and this memo are explained in AppendixE. The differences consist of bug fixes and clarifications, and are backward-compatible in nature. Implementations of RFC 1247 and of this memo will interoperate.
Please send comments to ospf@gated.cornell.edu.

RFC 1584 Multicast Extensions to OSPF

Authors: J. Moy.

Date: March 1994

Formats: txt html pdf json ps

Status: HISTORIC

DOI: 10.17487/RFC 1584

This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. In this proposal, an IP multicast packet is routed based both on the packet's source and its multicast destination (commonly referred to as source/destination routing). As it is routed, the multicast packet follows a shortest path to each multicast destination. During packet forwarding, any commonality of paths is exploited; when multiple hosts belong to a single multicast group, a multicast packet will be replicated only when the paths to the separate hosts diverge.
OSPF, a link-state routing protocol, provides a database describing the Autonomous System's topology. A new OSPF link state advertisement is added describing the location of multicast destinations. A multicast packet's path is then calculated by building a pruned shortest-path tree rooted at the packet's IP source. These trees are built on demand, and the results of the calculation are cached for use by subsequent packets.
The multicast extensions are built on top of OSPF Version 2. The extensions have been implemented so that a multicast routing capability can be introduced piecemeal into an OSPF Version 2 routing domain. Some of the OSPF Version 2 routers may run the multicast extensions, while others may continue to be restricted to the forwarding of regular IP traffic (unicasts).
Please send comments to mospf@gated.cornell.edu.

RFC 1585 MOSPF: Analysis and Experience

Authors: J. Moy.

Date: March 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1585

This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering TaskForce internet routing protocol standardization criteria" ([RFC1264]).
Please send comments to mospf@gated.cornell.edu.

RFC 1586 Guidelines for Running OSPF Over Frame Relay Networks

Authors: O. deSouza, M. Rodrigues.

Date: March 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1586

This memo specifies guidelines for implementors and users of the OpenShortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. We show how to configure frame relay interfaces in a way that obviates the "full-mesh" connectivity required by current OSPF implementations. This allows for simpler, more economic network designs. These guidelines do not require any protocol changes; they only provide recommendations for how OSPF should be implemented and configured to use frame relay networks efficiently.

RFC 1587 The OSPF NSSA Option

Authors: R. Coltun, V. Fuller.

Date: March 1994

Formats: txt json html

Obsoleted by: RFC 3101

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1587

This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK]

RFC 1588 White Pages Meeting Report

Authors: J. Postel, C. Anderson.

Date: February 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1588

This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1589 A Kernel Model for Precision Timekeeping

Authors: D. Mills.

Date: March 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1589

This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1590 Media Type Registration Procedure

Authors: J. Postel.

Date: March 1994

Formats: txt html json

Obsoleted by: RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049

Updates: RFC 1521

Status: INFORMATIONAL

DOI: 10.17487/RFC 1590

Several protocols allow the use of data representing different"media" such as text, images, audio, and video, and within such media different encoding styles, such as (in video) jpeg, gif, ief, and tiff. The Multimedia Internet Message Extensions (MIME) protocol [1] defined several initial types of multimedia data objects, and a procedure for registering additional types with the Internet AssignedNumbers Authority (IANA). Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content- type/subtypes). It also generalizes the scope of use of these MediaTypes to make it appropriate to use the same registrations and specifications with other applications.

RFC 1591 Domain Name System Structure and Delegation

Authors: J. Postel.

Date: March 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1591

This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0

Authors: B. Wijnen, G. Carpenter, K. Curran, A. Sehgal, G. Waters.

Date: March 1994

Formats: txt json html

Obsoletes: RFC 1228

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1592

This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1593 SNA APPN Node MIB

Authors: W. McKenzie, J. Cheng.

Date: March 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1593

This RFC describes IBM's SNMP support for SNA Advanced Peer-to-PeerNetworking (APPN) nodes.

RFC 1594 FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions

Authors: A. Marine, J. Reynolds, G. Malkin.

Date: March 1994

Formats: txt html json

Obsoletes: RFC 1325

Obsoleted by: RFC 2664

Status: INFORMATIONAL

DOI: 10.17487/RFC 1594

This FYI RFC is one of two FYI's called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet.

RFC 1595 Definitions of Managed Objects for the SONET/SDH Interface Type

Authors: T. Brown, K. Tesink.

Date: March 1994

Formats: txt html json

Obsoleted by: RFC 2558

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1595

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407[13].
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

RFC 1596 Definitions of Managed Objects for Frame Relay Service

Authors: T. Brown, Ed..

Date: March 1994

Formats: txt json html

Obsoleted by: RFC 1604

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1596

This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service.

RFC 1597 Address Allocation for Private Internets

Authors: Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot.

Date: March 1994

Formats: txt json html

Obsoleted by: RFC 1918

Status: INFORMATIONAL

DOI: 10.17487/RFC 1597

This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1598 PPP in X.25

Authors: W. Simpson.

Date: March 1994

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1598

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of X.25 for framing PPP encapsulated packets.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list.

RFC 1599 Summary of 1500-1599

Authors: M. Kennedy.

Date: January 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1599

RFC 1600 Internet Official Protocol Standards

Authors: J. Postel.

Date: March 1994

Formats: txt html json

Obsoletes: RFC 1540

Obsoleted by: RFC 1610

Status: HISTORIC

DOI: 10.17487/RFC 1600

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC 1601 Charter of the Internet Architecture Board (IAB)

Authors: C. Huitema.

Date: March 1994

Formats: txt html json

Obsoletes: RFC 1358

Obsoleted by: RFC 2850

Status: INFORMATIONAL

DOI: 10.17487/RFC 1601

This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations.

RFC 1602 The Internet Standards Process -- Revision 2

Authors: Internet Architecture Board, Internet Engineering Steering Group.

Date: March 1994

Formats: txt json html

Obsoletes: RFC 1310

Obsoleted by: RFC 2026

Updated by: RFC 1871

Status: INFORMATIONAL

DOI: 10.17487/RFC 1602

This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.
This revision (revision 2) includes the following major changes:
(a) The new management structure arising from the POISED WorkingGroup is reflected. These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting.
(b) Prototype status is added to the non-standards track maturity levels (Section 2.4.1).
(c) The Intellectual Property Rights section is completely revised, in accordance with legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. The new section 5 has been reviewed by legal counsel to the Internet Society.
(d) An appeals procedure is added (Section 3.6).
(e) The wording of sections 1 and 1.2 has been changed to clarify the relationships that exist between the Internet Society and the IAB, the IESG, the IETF, and the Internet Standards process.
(f) An Appendix B has been added, listing the contact points for theRFC editor, the IANA, the IESG, the IAB and the ISOC. The"future issues" are now listed in Appendix C.

RFC 1603 IETF Working Group Guidelines and Procedures

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 1604 Definitions of Managed Objects for Frame Relay Service

Authors: T. Brown, Ed..

Date: March 1994

Formats: txt html json

Obsoletes: RFC 1596

Obsoleted by: RFC 2954

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1604

This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service.

RFC 1605 SONET to Sonnet Translation

Authors: W. Shakespeare.

Date: 1 April 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1605

Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation(SONNET).

RFC 1606 A Historical Perspective On The Usage Of IP Version 9

Authors: J. Onions.

Date: 1 April 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1606

This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures.

RFC 1607 A VIEW FROM THE 21ST CENTURY

Authors: V. Cerf.

Date: 1 April 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1607

This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1608 Representing IP Information in the X.500 Directory

Authors: T. Johannsen, G. Mansfield, M. Kosters, S. Sataluri.

Date: March 1994

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1608

This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory" [1] where a general framework is presented for representing networks in theDirectory by applying it to IP networks. This application of theDirectory is intended to support the work of IP network assigning authorities, NICs, as well as other applications looking for a mapping of IP numbers to data of related networks. Furthermore,Autonomous Systems and related routing policy information can be represented in the Directory along with their relationship to networks and organizations.

RFC 1609 Charting Networks in the X.500 Directory

Authors: G. Mansfield, T. Johannsen, M. Knopper.

Date: March 1994

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1609

There is a need for a framework wherein the infrastructural and service related information about communication networks can be made accessible from all places and at all times in a reasonably efficient manner and with reasonable accuracy. This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. Schemas of objects and their attributes which may be used for this purpose are presented. The model envisages physical objects and several logical abstractions of the physical objects.

RFC 1610 Internet Official Protocol Standards

Authors: J. Postel.

Date: July 1994

Formats: txt html json

Obsoletes: RFC 1600

Obsoleted by: RFC 1720

Status: HISTORIC

DOI: 10.17487/RFC 1610

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC 1611 DNS Server MIB Extensions

Authors: R. Austein, J. Saperia.

Date: May 1994

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1611

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS name server functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]

RFC 1612 DNS Resolver MIB Extensions

Authors: R. Austein, J. Saperia.

Date: May 1994

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1612

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS resolver functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]

RFC 1613 cisco Systems X.25 over TCP (XOT)

Authors: J. Forster, G. Satz, G. Glick, R. Day.

Date: May 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1613

This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1614 Network Access to Multimedia Information

Authors: C. Adie.

Date: May 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1614

This report summarises the requirements of research and academic network users for network access to multimedia information. It does this by investigating some of the projects planned or currently underway in the community. Existing information systems such asGopher, WAIS and World-Wide Web are examined from the point of view of multimedia support, and some interesting hypermedia systems emerging from the research community are also studied. Relevant existing and developing standards in this area are discussed. The report identifies the gaps between the capabilities of currentlydeployed systems and the user requirements, and proposes further work centred on the World-Wide Web system to rectify this.
The report is in some places very detailed, so it is preceded by an extended summary, which outlines the findings of the report.

RFC 1615 Migrating from X.400(84) to X.400(88)

Authors: J. Houttuin, J. Craigie.

Date: May 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1615

This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. It not only describes the technical complications, but also the effect the transition will have on the end users, especially concerning interworking between end users of the 84 and the 88 services.

RFC 1616 X.400(1988) for the Academic and Research Community in Europe

Authors: RARE WG-MSG Task Force 88, E. Huizer, Ed., J. Romaguera, Ed..

Date: May 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1616

The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1617 Naming and Structuring Guidelines for X.500 Directory Pilots

Authors: P. Barker, S. Kille, T. Lenggenhager.

Date: May 1994

Formats: txt json html

Obsoletes: RFC 1384

Status: INFORMATIONAL

DOI: 10.17487/RFC 1617

Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. The final version of this document will replace RFC 1384.

RFC 1618 PPP over ISDN

Authors: W. Simpson.

Date: May 1994

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1618

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Integrated ServicesDigital Network (ISDN) switched circuits.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list.

RFC 1619 PPP over SONET/SDH

Authors: W. Simpson.

Date: May 1994

Formats: txt html json

Obsoleted by: RFC 2615

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1619

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Synchronous OpticalNetwork (SONET) and Synchronous Digital Heirarchy (SDH) circuits.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list.

RFC 1620 Internet Architecture Extensions for Shared Media

Authors: B. Braden, J. Postel, Y. Rekhter.

Date: May 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1620

The original Internet architecture assumed that each network is labeled with a single IP network number. This assumption may be violated for shared media, including "large public data networks"(LPDNs). The architecture still works if this assumption is violated, but it does not have a means to prevent multiple host- router and router-router hops through the shared medium. This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops.

RFC 1621 Pip Near-term Architecture

Authors: P. Francis.

Date: May 1994

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1621

Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to evolve to all forseeable internet protocol requirements. This specification describes the routing and addressing architecture for near-term Pip deployment. We say near-term only because Pip is designed with evolution in mind, so other architectures are expected in the future. This document, however, makes no reference to such future architectures.

RFC 1622 Pip Header Processing

Authors: P. Francis.

Date: May 1994

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1622

Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification defines the Pip header processing for Routers andHosts.

RFC 1623 Definitions of Managed Objects for the Ethernet-like Interface Types

Authors: F. Kastenholz.

Date: May 1994

Formats: txt json html

Obsoletes: RFC 1398

Obsoleted by: RFC 1643

Status: HISTORIC

DOI: 10.17487/RFC 1623

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC 1624 Computation of the Internet Checksum via Incremental Update

Authors: A. Rijsinghani, Ed..

Date: May 1994

Formats: txt html json

Updates: RFC 1141

Status: INFORMATIONAL

DOI: 10.17487/RFC 1624

This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141.

RFC 1625 WAIS over Z39.50-1988

Authors: M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle, J. Kunze, H. Morris, F. Schiettecatte.

Date: June 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1625

The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1626 Default IP MTU for use over ATM AAL5

Authors: R. Atkinson.

Date: May 1994

Formats: txt json html

Obsoleted by: RFC 2225

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1626

There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK]

RFC 1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified)

Authors: E. Lear, E. Fair, D. Crocker, T. Kessler.

Date: July 1994

Formats: txt json html

Obsoleted by: RFC 1918

Status: INFORMATIONAL

DOI: 10.17487/RFC 1627

This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1628 UPS Management Information Base

Authors: J. Case, Ed..

Date: May 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1628

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. [STANDARDS-TRACK]

RFC 1629 Guidelines for OSI NSAP Allocation in the Internet

Authors: R. Colella, R. Callon, E. Gardner, Y. Rekhter.

Date: May 1994

Formats: txt html json

Obsoletes: RFC 1237

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1629

CLNP is currently being deployed in the Internet. This is useful to support OSI and DECnet(tm) traffic. In addition, CLNP has been proposed as a possible IPng candidate, to provide a long-term solution to IP address exhaustion. Required as part of the CLNP infrastructure are guidelines for network service access point (NSAP) address assignment. This paper provides guidelines for allocatingNSAP addresses in the Internet.
The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration.

RFC 1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web

Authors: T. Berners-Lee.

Date: June 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1630

This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1631 The IP Network Address Translator (NAT)

Authors: K. Egevang, P. Francis.

Date: May 1994

Formats: txt html json

Obsoleted by: RFC 3022

Status: INFORMATIONAL

DOI: 10.17487/RFC 1631

The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses.
It is possible that CIDR will not be adequate to maintain the IPInternet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complementsCIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local IP addresses and globally unique addresses. The IP addresses inside the stub domain are not globally unique. They are reused in other domains, thus solving the address depletion problem. The globally unique IP addresses are assigned according to current CIDR address allocation schemes. CIDR solves the scaling problem. The main advantage of NAT is that it can be installed without changes to routers or hosts. This memo presents a preliminary design for NAT, and discusses its pros and cons.

RFC 1632 A Revised Catalog of Available X.500 Implementations

Authors: A. Getchell, Ed., S. Sataluri, Ed..

Date: May 1994

Formats: txt json html

Obsoletes: RFC 1292

Obsoleted by: RFC 2116

Status: INFORMATIONAL

DOI: 10.17487/RFC 1632

This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. We contacted each contributor inRFC 1292 and requested an update and published the survey template in several mailing lists and obtained new product descriptions.
This document contains detailed description of twenty six (26) X.500 implementations - DSAs, DUAs, and DUA interfaces.

RFC 1633 Integrated Services in the Internet Architecture: an Overview

Authors: R. Braden, D. Clark, S. Shenker.

Date: June 1994

Formats: txt json ps html pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 1633

This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real- time as well as the current non-real-time service of IP. This extension is necessary to meet the growing need for real-time service for a variety of new applications, including teleconferencing, remote seminars, telescience, and distributed simulation.
This memo represents the direct product of recent work by Dave Clark,Scott Shenker, Lixia Zhang, Deborah Estrin, Sugih Jamin, JohnWroclawski, Shai Herzog, and Bob Braden, and indirectly draws upon the work of many others.

RFC 1634 Novell IPX Over Various WAN Media (IPXWAN)

Authors: M. Allen.

Date: May 1994

Formats: txt html json

Obsoletes: RFC 1551, RFC 1362

Status: INFORMATIONAL

DOI: 10.17487/RFC 1634

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and RFC 1551. The changes from RFC 1551 are to correct a problem in the wording when anRFC 1362 router talks to an RFC 1551 router and to allow numbers to be specified in a Router Name.

RFC 1635 How to Use Anonymous FTP

Authors: P. Deutsch, A. Emtage, A. Marine.

Date: May 1994

Formats: txt html json

Also: FYI 0024

Status: INFORMATIONAL

DOI: 10.17487/RFC 1635

This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. It shows a sample anonymous FTP session. It also discusses common ways files are packaged for efficient storage and transmission.

RFC 1636 Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994

Authors: R. Braden, D. Clark, S. Crocker, C. Huitema.

Date: June 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1636

This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture.
This document should be regarded as a set of working notes containing ideas about security that were developed by Internet experts in a broad spectrum of areas, including routing, mobility, realtime service, and provider requirements, as well as security. It contains some significant diversity of opinions on some important issues.This memo is offered as one input in the process of developing viable security mechanisms and procedures for the Internet.

RFC 1637 DNS NSAP Resource Records

Authors: B. Manning, R. Colella.

Date: June 1994

Formats: txt json html

Obsoletes: RFC 1348

Obsoleted by: RFC 1706

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1637

The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure is support in the Domain NameSystem (DNS) for mapping between names and NSAP addresses.
This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with anyNSAP address format. This document supercedes RFC 1348.
NSAP-to-name translation is accomplished through use of the PTR RR(see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation.

RFC 1638 PPP Bridging Control Protocol (BCP)

Authors: F. Baker, R. Bowen.

Date: June 1994

Formats: txt html json

Obsoletes: RFC 1220

Obsoleted by: RFC 2878

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1638

The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links.

RFC 1639 FTP Operation Over Big Address Records (FOOBAR)

Authors: D. Piscitello.

Date: June 1994

Formats: txt html json

Obsoletes: RFC 1545

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1639

This paper describes a convention for specifying address families other than the default Internet address family in FTP commands and replies.

RFC 1640 The Process for Organization of Internet Standards Working Group (POISED)

Authors: S. Crocker.

Date: June 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1640

This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992. Necessarily, this synopsis represents my own perception, particularly for the "prehistory" period. Quite a few people hold strong views about both the overall sequence and specific events. My intent here is to convey as neutral a point of view as possible.

RFC 1641 Using Unicode with MIME

Authors: D. Goldsmith, M. Davis.

Date: July 1994

Formats: txt json html ps pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1641

The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document specifies the usage of Unicode within MIME.

RFC 1642 UTF-7 - A Mail-Safe Transformation Format of Unicode

Authors: D. Goldsmith, M. Davis.

Date: July 1994

Formats: txt html pdf ps json

Obsoleted by: RFC 2152

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1642

The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of RFC 1521, RFC 1522, and the document "Using Unicode with MIME".

RFC 1643 Definitions of Managed Objects for the Ethernet-like Interface Types

Authors: F. Kastenholz.

Date: July 1994

Formats: txt html json

Obsoletes: RFC 1623

Obsoleted by: RFC 3638

Status: HISTORIC

DOI: 10.17487/RFC 1643

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC 1644 T/TCP -- TCP Extensions for Transactions Functional Specification

Authors: R. Braden.

Date: July 1994

Formats: txt json html

Obsoleted by: RFC 6247

Updates: RFC 1379

Status: HISTORIC

DOI: 10.17487/RFC 1644

This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This backwards-compatible extension could fill the gap between the current connection-oriented TCP and the datagram-based UDP.
This work was supported in part by the National Science Foundation under Grant Number NCR-8922231.

RFC 1645 Simple Network Paging Protocol - Version 2

Authors: A. Gwinn.

Date: July 1994

Formats: txt json html

Obsoletes: RFC 1568

Obsoleted by: RFC 1861

Status: INFORMATIONAL

DOI: 10.17487/RFC 1645

This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months for nationwide paging and messaging. In addition, email filters and SNPP client software for Unix and Windows are available at no cost. Please contact the author for more information.
Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below.

RFC 1646 TN3270 Extensions for LUname and Printer Selection

Authors: C. Graves, T. Butts, M. Angel.

Date: July 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1646

This document describes protocol extensions to TN3270. There are two extensions outlined in this document. The first defines a way by which a TN3270 client can request a specific device (LUname) from aTN3270 server. The second extension specifies how a TN3270 printer device can be requested by a TN3270 client and the manner in which the 3270 printer status information can be sent to the TN3270 server.Discussions and suggestions for improvements to these enhancements should be sent to the TN3270E Working Group mailing listTN3270E@list.nih.gov . These extensions will be called TN3287 in this document. This information is being provided to members of theInternet community that want to support the 3287 data stream within the TELNET protocol.

RFC 1647 TN3270 Enhancements

Authors: B. Kelly.

Date: July 1994

Formats: txt html json

Obsoleted by: RFC 2355

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1647

This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device- name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, theSYSREQ key, and SNA response handling.
This protocol would be negotiated and implemented under a new TelnetOption and would be unrelated to the Telnet 3270 Regime Option as defined in RFC 1041 [1].

RFC 1648 Postmaster Convention for X.400 Operations

Authors: A. Cargille.

Date: July 1994

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1648

Both STD 11, RFC 822 [1] and STD 3, RFC 1123 [2] (Host Requirements) require that the email address "postmaster" be supported at all hosts. This paper extends this concept to X.400 mail domains which have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses.

RFC 1649 Operational Requirements for X.400 Management Domains in the GO-MHS Community

Authors: R. Hagens, A. Hansen.

Date: July 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1649

The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1650 Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2

Authors: F. Kastenholz.

Date: August 1994

Formats: txt json html

Obsoleted by: RFC 2358

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1650

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC 1651 SMTP Service Extensions

Authors: J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker.

Date: July 1994

Formats: txt json html

Obsoletes: RFC 1425

Obsoleted by: RFC 1869

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1651

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

RFC 1652 SMTP Service Extension for 8bit-MIMEtransport

Authors: J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker.

Date: July 1994

Formats: txt html json

Obsoletes: RFC 1426

Obsoleted by: RFC 6152

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1652

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP.

RFC 1653 SMTP Service Extension for Message Size Declaration

Authors: J. Klensin, N. Freed, K. Moore.

Date: July 1994

Formats: txt html json

Obsoletes: RFC 1427

Obsoleted by: RFC 1870

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1653

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size.

RFC 1654 A Border Gateway Protocol 4 (BGP-4)

Authors: Y. Rekhter, Ed., T. Li, Ed..

Date: July 1994

Formats: txt json html

Obsoleted by: RFC 1771

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1654

This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC 1655 Application of the Border Gateway Protocol in the Internet

Authors: Y. Rekhter, Ed., P. Gross, Ed..

Date: July 1994

Formats: txt json html

Obsoletes: RFC 1268

Obsoleted by: RFC 1772

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1655

This document, together with its companion document, "A BorderGateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4(BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.
Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net).

RFC 1656 BGP-4 Protocol Document Roadmap and Implementation Experience

Authors: P. Traina.

Date: July 1994

Formats: txt html json

Obsoleted by: RFC 1773

Status: INFORMATIONAL

DOI: 10.17487/RFC 1656

Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2

Authors: S. Willis, J. Burruss, J. Chu, Ed..

Date: July 1994

Formats: txt html json

Obsoleted by: RFC 4273

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1657

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK]

RFC 1658 Definitions of Managed Objects for Character Stream Devices using SMIv2

Authors: B. Stewart.

Date: July 1994

Formats: txt json html

Obsoletes: RFC 1316

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1658

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. [STANDARDS-TRACK]

RFC 1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2

Authors: B. Stewart.

Date: July 1994

Formats: txt json html

Obsoletes: RFC 1317

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1659

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]

RFC 1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2

Authors: B. Stewart.

Date: July 1994

Formats: txt json html

Obsoletes: RFC 1318

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1660

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer- like devices. [STANDARDS-TRACK]

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 1662 PPP in HDLC-like Framing

Authors: W. Simpson, Ed..

Date: July 1994

Formats: txt html json

Obsoletes: RFC 1549

Also: STD 0051

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1662

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of HDLC-like framing for PPP encapsulated packets.

RFC 1663 PPP Reliable Transmission

Authors: D. Rand.

Date: July 1994

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1663

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link.
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 1664 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables

Authors: C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens.

Date: August 1994

Formats: txt json html

Obsoleted by: RFC 2163

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1664

This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to mapRFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Gateways located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This memo is a joint effort of X400 operation working group (x400ops) and RARE Mail andMessaging working group (WG-MSG).

RFC 1665 Definitions of Managed Objects for SNA NAUs using SMIv2

Authors: Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed..

Date: July 1994

Formats: txt json html

Obsoleted by: RFC 1666

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1665

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]

RFC 1666 Definitions of Managed Objects for SNA NAUs using SMIv2

Authors: Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed..

Date: August 1994

Formats: txt html json

Obsoletes: RFC 1665

Status: HISTORIC

DOI: 10.17487/RFC 1666

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]

RFC 1667 Modeling and Simulation Requirements for IPng

Authors: S. Symington, D. Wood, M. Pullen.

Date: August 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1667

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 big-internet@munnari.oz.au mailing list.

RFC 1668 Unified Routing Requirements for IPng

Authors: D. Estrin, T. Li, Y. Rekhter.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1668

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 big-internet@munnari.oz.au mailing list.

RFC 1669 Market Viability as a IPng Criteria

Authors: J. Curran.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1669

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 big-internet@munnari.oz.au mailing list.

RFC 1670 Input to IPng Engineering Considerations

Authors: D. Heagerty.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1670

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 big-internet@munnari.oz.au mailing list.

RFC 1671 IPng White Paper on Transition and Other Considerations

Authors: B. Carpenter.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1671

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 big-internet@munnari.oz.au mailing list.

RFC 1672 Accounting Requirements for IPng

Authors: N. Brownlee.

Date: August 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1672

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 big-internet@munnari.oz.au mailing list.

RFC 1673 Electric Power Research Institute Comments on IPng

Authors: R. Skelton.

Date: August 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1673

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 big-internet@munnari.oz.au mailing list.

RFC 1674 A Cellular Industry View of IPng

Authors: M. Taylor.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1674

This memo is a response to RFC 1550, "IP: Next Generation (IPng)White Paper Solicitation". The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cellular industry, the Cellular Digital Packet Data (CDPD) consortium of service providers or any of its constituent companies.

RFC 1675 Security Concerns for IPng

Authors: S. Bellovin.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1675

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 big-internet@munnari.oz.au mailing list.

RFC 1676 INFN Requirements for an IPng

Authors: A. Ghiselli, D. Salomoni, C. Vistoli.

Date: August 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1676

This white paper is sent by INFN network team, the Italian NationalInstitute for nuclear physics, whose network, named INFNet, is a nationwide network founded to provide the access to existing national and international HEP laboratory and to facilitate communications between the researchers. With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan.We do not really expect to add original items to the selection, but we think that it could be useful to submit the opinions and ideas that come from our network experience.

RFC 1677 Tactical Radio Frequency Communication Requirements for IPng

Authors: B. Adamson.

Date: August 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1677

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 big-internet@munnari.oz.au mailing list.

RFC 1678 IPng Requirements of Large Corporate Networks

Authors: E. Britton, J. Tavs.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1678

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 big-internet@munnari.oz.au mailing list. This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite.

RFC 1679 HPN Working Group Input to the IPng Requirements Solicitation

Authors: D. Green, P. Irey, D. Marlow, K. O'Donoghue.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1679

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 big-internet@munnari.oz.au mailing list.

RFC 1680 IPng Support for ATM Services

Authors: C. Brazdziunas.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1680

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 big-internet@munnari.oz.au mailing list.

RFC 1681 On Many Addresses per Host

Authors: S. Bellovin.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1681

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 big-internet@munnari.oz.au mailing list.

RFC 1682 IPng BSD Host Implementation Analysis

Authors: J. Bound.

Date: August 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1682

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 big-internet@munnari.oz.au mailing list.

RFC 1683 Multiprotocol Interoperability In IPng

Authors: R. Clark, M. Ammar, K. Calvert.

Date: August 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1683

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 big-internet@munnari.oz.au mailing list.

RFC 1684 Introduction to White Pages Services based on X.500

Authors: P. Jurg.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1684

This document aims at organisations who are using local and global electronic communication on a day to day basis and for whom using an electronic White Pages Service is therefore indispensable.
The document provides an introduction to the international ITU-T(formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic WhitePages Service.
In addition a short overview of the experience gained from theParadise X.500 pilot is given. References to more detailed information are included.
The document should be useful for managers of the above mentioned organisations who need to get the necessary executive commitment for making the address information of their organisation available by means of X.500.

RFC 1685 Writing X.400 O/R Names

Authors: H. Alvestrand.

Date: August 1994

Formats: txt json html

Also: RTR_0012

Status: INFORMATIONAL

DOI: 10.17487/RFC 1685

There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way. This memo is a discussion of this topic. This memo provides information for the Internet Community. It does not specify an Internet Standard of any kind.

RFC 1686 IPng Requirements: A Cable Television Industry Viewpoint

Authors: M. Vecchi.

Date: August 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1686

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. The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cable television industry or any of its companies. Comments should be submitted to the big-internet@munnari.oz.au mailing list.

RFC 1687 A Large Corporate User's View of IPng

Authors: E. Fleischman.

Date: August 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1687

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 big-internet@munnari.oz.au mailing list.

RFC 1688 IPng Mobility Considerations

Authors: W. Simpson.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1688

This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.

RFC 1689 A Status Report on Networked Information Retrieval: Tools and Groups

Authors: J. Foster, Ed..

Date: August 1994

Formats: txt json html

Also: FYI 0025

Status: INFORMATIONAL

DOI: 10.17487/RFC 1689

The purpose of this report is to increase the awareness of NetworkedInformation Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools.NIR Tools covered include Archie, WAIS, gopher and World Wide Web.

RFC 1690 Introducing the Internet Engineering and Planning Group (IEPG)

Authors: G. Huston.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1690

This memo introduces the IEPG to the Internet Community. The IEPG is an Internet Service Operators' forum, intended to assist ServiceOperators to coordinate in operational aspects of managing Internet services.

RFC 1691 The Document Architecture for the Cornell Digital Library

Authors: W. Turner.

Date: August 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1691

This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library.
Two unique features of this architecture are the ability to generate reference documents and the ability to create multiple views of a document.

RFC 1692 Transport Multiplexing Protocol (TMux)

Authors: P. Cameron, D. Crocker, D. Cohen, J. Postel.

Date: August 1994

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1692

One of the problems with the use of terminal servers is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. TMux is a protocol which allows multiple short transport segments, independent of application type, to be combined between a server and host pair.

RFC 1693 An Extension to TCP : Partial Order Service

Authors: T. Connolly, P. Amer, P. Conrad.

Date: November 1994

Formats: txt html json

Obsoleted by: RFC 6247

Status: HISTORIC

DOI: 10.17487/RFC 1693

This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. Distribution of this memo is unlimited.

RFC 1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2

Authors: T. Brown, Ed., K. Tesink, Ed..

Date: August 1994

Formats: txt json html

Obsoletes: RFC 1304

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1694

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 objects for SMDS access interfaces. This includes the following access protocols:
SIP [13]SIP/DXI [18] and [20]SIP/FR [19]SIP/ATM [24]
This memo replaces RFC 1304 [12], and defines a MIB module which is both compliant to the SNMPv2 SMI and semantically-identical to the existing RFC 1304-based definitions.
This memo also assumes application of the MIB II Interfaces group as defined in [9].

RFC 1695 Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2

Authors: M. Ahmed, Ed., K. Tesink, Ed..

Date: August 1994

Formats: txt json html

Obsoleted by: RFC 2515

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1695

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

RFC 1696 Modem Management Information Base (MIB) using SMIv2

Authors: J. Barnes, L. Brown, R. Royston, S. Waldbusser.

Date: August 1994

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1696

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 dial-up modems and similar dial-up devices. [STANDARDS-TRACK]

RFC 1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2

Authors: D. Brower, Ed., B. Purvy, A. Daniel, M. Sinykin, J. Smith.

Date: August 1994

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1697

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 relational database (RDBMS) implementations. [STANDARDS-TRACK]

RFC 1698 Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications

Authors: P. Furniss.

Date: October 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1698

This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". These include OSI application protocols such as X.400 P7 and DirectoryAccess Protocol, and "migrant" protocols, originally defined for use over other transports.
As well as the octet sequences which are the supporting layer headers(and trailers) around the application data, this document includes some tutorial material on the OSI upper layers.
An implementation that sends the octet sequences given here, and interprets the equivalent protocol received, will be able to interwork with an implementation based on the base standard, when both are being used to support an appropriate application protocol.

RFC 1699 Summary of 1600-1699

Authors: J. Elliott.

Date: January 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1699

RFC 1700 Assigned Numbers

Authors: J. Reynolds, J. Postel.

Date: October 1994

Formats: txt json html

Obsoletes: RFC 1340

Obsoleted by: RFC 3232

Status: HISTORIC

DOI: 10.17487/RFC 1700

This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.

RFC 1701 Generic Routing Encapsulation (GRE)

Authors: S. Hanks, T. Li, D. Farinacci, P. Traina.

Date: October 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1701

This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.

RFC 1702 Generic Routing Encapsulation over IPv4 networks

Authors: S. Hanks, T. Li, D. Farinacci, P. Traina.

Date: October 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1702

This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures

Authors: M. Rose.

Date: October 1994

Formats: txt html json

Obsoletes: RFC 1569

Status: INFORMATIONAL

DOI: 10.17487/RFC 1703

This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1704 On Internet Authentication

Authors: N. Haller, R. Atkinson.

Date: October 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1704

This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1705 Six Virtual Inches to the Left: The Problem with IPng

Authors: R. Carlson, D. Ficarella.

Date: October 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1705

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 big-internet@munnari.oz.au mailing list.

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 1707 CATNIP: Common Architecture for the Internet

Authors: M. McGovern, R. Ullmann.

Date: October 1994

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1707

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 big-internet@munnari.oz.au mailing list.

RFC 1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3

Authors: D. Gowin.

Date: October 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1708

This RFC describes a PICS Proforma translated into an Internet acceptable form. The Original document was developed according toISO 9646 for conformance test purposes. This document is intended for both developers and users of the NTP (Network Time Protocol).This document contains specific information and performance characteristics for the use of NTP within the context of Internet usage. It is suggested, that users wishing to use the synchronization capabilities of the Internet abide by the characteristics set within this document.
For more information please contact Dr. David Mills at Mills@udel.edu or review RFC 1305 for more information.

RFC 1709 K-12 Internetworking Guidelines

Authors: J. Gargano, D. Wasley.

Date: November 1994

Formats: txt json ps pdf html

Also: FYI 0026

Status: INFORMATIONAL

DOI: 10.17487/RFC 1709

The K-12 community traditionally has not had this level of staffing available for telecommunications planning. This document is intended to bridge that gap and provides a recommended technical direction, an introduction to the role the Internet now plays in K-12 education and technical guidelines for building a campus data communications infrastructure that provides internetworking services and connections to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1710 Simple Internet Protocol Plus White Paper

Authors: R. Hinden.

Date: October 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1710

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 1711 Classifications in E-mail Routing

Authors: J. Houttuin.

Date: October 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1711

This paper presents a classification for e-mail routing issues. It clearly defines commonly used terminology such as static routing, store-and-forward routing, source routing and others. Real life examples show which routing options are used in existing projects.
The goal is to define all terminology in one reference paper. This will also help relatively new mail system managers to understand the issues and make the right choices. The reader is expected to already have a solid understanding of general networking terminology.
In this paper, the word Message Transfer Agent (MTA) is used to describe a routing entity, which can be an X.400 MTA, a UNIX mailer, or any other piece of software performing mail routing functions. AnMTA processes the so called envelope information of a message. The term User Agent (UA) is used to describe a piece of software performing user related mail functions. It processes the contents of a message's envelope, i.e., the header fields and body parts.

RFC 1712 DNS Encoding of Geographical Location

Authors: C. Farrell, M. Schulze, S. Pleitner, D. Baldoni.

Date: November 1994

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1712

This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This definition deals with associating geographical host location mappings to host names within a domain.The data shown in this document is fictitious and does not necessarily reflect the real Internet.

RFC 1713 Tools for DNS debugging

Authors: A. Romao.

Date: November 1994

Formats: txt html json

Also: FYI 0027

Status: INFORMATIONAL

DOI: 10.17487/RFC 1713

Although widely used (and most of the times unnoticed), DNS (DomainName System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work.This document presents some tools available for domain administrators to detect and correct those anomalies.

RFC 1714 Referral Whois Protocol (RWhois)

Authors: S. Williamson, M. Kosters.

Date: November 1994

Formats: txt ps json pdf html

Obsoleted by: RFC 2167

Status: INFORMATIONAL

DOI: 10.17487/RFC 1714

This memo describes version 1.0 of the client/server interaction ofRWhois. RWhois provides a distributed system for the display of hierarchical information. This system is hierarchical by design, allowing for the reduction of a query, and the referral of the user closer to the maintainer of the information.

RFC 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 1716 Towards Requirements for IP Routers

Authors: P. Almquist, F. Kastenholz.

Date: November 1994

Formats: txt html json

Obsoleted by: RFC 1812

Status: INFORMATIONAL

DOI: 10.17487/RFC 1716

The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1717 The PPP Multilink Protocol (MP)

Authors: K. Sklower, B. Lloyd, G. McGregor, D. Carr.

Date: November 1994

Formats: txt html json

Obsoleted by: RFC 1990

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1717

This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links. This is accomplished by means of new PPP [2] options and protocols.

RFC 1718 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force

Authors: IETF Secretariat, G. Malkin.

Date: November 1994

Formats: txt json html

Obsoletes: RFC 1539

Obsoleted by: RFC 3160

Status: INFORMATIONAL

DOI: 10.17487/RFC 1718

Over the last two years, the attendance at Internet Engineering TaskForce (IETF) plenary meetings has grown phenomenally. Approximately one third of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought provoking e-mail messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.

RFC 1719 A Direction for IPng

Authors: P. Gross.

Date: December 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1719

This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.

RFC 1720 Internet Official Protocol Standards

Authors: J. Postel.

Date: November 1994

Formats: txt json html

Obsoletes: RFC 1610

Obsoleted by: RFC 1780

Status: HISTORIC

DOI: 10.17487/RFC 1720

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC 1721 RIP Version 2 Protocol Analysis

Authors: G. Malkin.

Date: November 1994

Formats: txt json html

Obsoletes: RFC 1387

Status: INFORMATIONAL

DOI: 10.17487/RFC 1721

As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to advancing RIP-2 on the standards track.

RFC 1722 RIP Version 2 Protocol Applicability Statement

Authors: G. Malkin.

Date: November 1994

Formats: txt html json

Also: STD 0057

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1722

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet.This report is a prerequisite to advancing RIP-2 on the standards track.

RFC 1723 RIP Version 2 - Carrying Additional Information

Authors: G. Malkin.

Date: November 1994

Formats: txt html json

Obsoletes: RFC 1388

Obsoleted by: RFC 2453

Updates: RFC 1058

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1723

This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1,2], to expand the amount of useful information carried in RIP messages and to add a measure of security.This memo obsoletes RFC 1388, which specifies an update to the"Routing Information Protocol" STD 34, RFC 1058.
The RIP-2 protocol analysis is documented in RFC 1721 [4].
The RIP-2 applicability statement is document in RFC 1722 [5].
The RIP-2 MIB description is defined in RFC 1724 [3]. This memo obsoletes RFC 1389.

RFC 1724 RIP Version 2 MIB Extension

Authors: G. Malkin, F. Baker.

Date: November 1994

Formats: txt json html

Obsoletes: RFC 1389

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1724

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing RIP Version 2.

RFC 1725 Post Office Protocol - Version 3

Authors: J. Myers, M. Rose.

Date: November 1994

Formats: txt json html

Obsoletes: RFC 1460

Obsoleted by: RFC 1939

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1725

This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK]

RFC 1726 Technical Criteria for Choosing IP The Next Generation (IPng)

Authors: C. Partridge, F. Kastenholz.

Date: December 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1726

This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.

RFC 1727 A Vision of an Integrated Internet Information Service

Authors: C. Weider, P. Deutsch.

Date: December 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1727

This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration.

RFC 1728 Resource Transponders

Authors: C. Weider.

Date: December 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1728

Although a number of systems have been created in the last several years to provide resource location and navigation on the Internet, the information contained in these systems must be maintained and updated by hand. This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information.

RFC 1729 Using the Z39.50 Information Retrieval Protocol

Authors: C. Lynch.

Date: December 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1729

This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1730 Internet Message Access Protocol - Version 4

Authors: M. Crispin.

Date: December 1994

Formats: txt json html

Obsoleted by: RFC 2060, RFC 2061

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1730

The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server.IMAP4 permits manipulation of remote message folders, called"mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]).
IMAP4 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4 are accessed by the use of numbers.These numbers are either message sequence numbers (relative position from 1 to the number of messages in the mailbox) or unique identifiers (immutable, strictly ascending values assigned to each message, but which are not necessarily contiguous).
IMAP4 supports a single server. A mechanism for supporting multipleIMAP4 servers is discussed in [IMSP].
IMAP4 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP].
IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.Compatibility issues are discussed in [IMAP-COMPAT].

RFC 1731 IMAP4 Authentication Mechanisms

Authors: J. Myers.

Date: December 1994

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1731

The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK]

RFC 1732 IMAP4 Compatibility with IMAP2 and IMAP2bis

Authors: M. Crispin.

Date: December 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1732

This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1733 Distributed Electronic Mail Models in IMAP4

Authors: M. Crispin.

Date: December 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1733

There are three fundamental models of client/server email: offline, online, and disconnected use. IMAP4 can be used in any one of these three models. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1734 POP3 AUTHentication command

Authors: J. Myers.

Date: December 1994

Formats: txt json html

Obsoleted by: RFC 5034

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1734

This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]

RFC 1735 NBMA Address Resolution Protocol (NARP)

Authors: J. Heinanen, R. Govindan.

Date: December 1994

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1735

This document describes the NBMA Address Resolution Protocol (NARP).NARP can be used by a source terminal (host or router) connected to aNon-Broadcast, Multi-Access link layer (NBMA) network to find out theNBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. Although this document focuses on NARP in the context of IP, the technique is applicable to other network layer protocols as well. This RFC is a product of the Routing over Large Clouds Working Group of the IETF.

RFC 1736 Functional Recommendations for Internet Resource Locators

Authors: J. Kunze.

Date: February 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1736

This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1737 Functional Requirements for Uniform Resource Names

Authors: K. Sollins, L. Masinter.

Date: December 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1737

This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

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 1739 A Primer On Internet and TCP/IP Tools

Authors: G. Kessler, S. Shepard.

Date: December 1994

Formats: txt json html

Obsoleted by: RFC 2151

Status: INFORMATIONAL

DOI: 10.17487/RFC 1739

This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1740 MIME Encapsulation of Macintosh Files - MacMIME

Authors: P. Faltstrom, D. Crocker, E. Fair.

Date: December 1994

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1740

This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files, while allowing non-Macintosh systems access to data in standardized formats.

RFC 1741 MIME Content Type for BinHex Encoded Files

Authors: P. Faltstrom, D. Crocker, E. Fair.

Date: December 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1741

This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files. Only when available software and/or user practice dictates, should this method be employed. It is recommended to use application/applefile [FALT94] for maximum interoperability.

RFC 1742 AppleTalk Management Information Base II

Authors: S. Waldbusser, K. Frisa.

Date: January 1995

Formats: txt json html

Obsoletes: RFC 1243

Status: HISTORIC

DOI: 10.17487/RFC 1742

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 AppleTalk networks.
RFC 1243 defines a set of MIB objects for managing the lower layers of the AppleTalk protocol stack, up to the Network layer. This memo defines additional objects that exist in the AppleTalk portion of theMIB. These objects provide for the management of the transport and session layers of the AppleTalk protocol stack, as well as extensions to the lower layers. This is achieved in an upwardly-compatable fashion.

RFC 1743 IEEE 802.5 MIB using SMIv2

Authors: K. McCloghrie, E. Decker.

Date: December 1994

Formats: txt json html

Obsoletes: RFC 1231

Obsoleted by: RFC 1748

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1743

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 1744 Observations on the Management of the Internet Address Space

Authors: G. Huston.

Date: December 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1744

This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. Possible modifications to the management practices are examined, and potential outcomes considered. Some general conclusions are drawn, and the relevance of these conclusions to the matter of formulation of address management policies for IPv6 are noted.

RFC 1745 BGP4/IDRP for IP---OSPF Interaction

Authors: K. Varadhan, S. Hares, Y. Rekhter.

Date: December 1994

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1745

This memo defines the various criteria to be used when designing anAutonomous System Border Router (ASBR) that will run either BGP4 orIDRP for IP with other ASBRs external to the AS and OSPF as its IGP.

RFC 1746 Ways to Define User Expectations

Authors: B. Manning, D. Perkins.

Date: December 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1746

This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet.

RFC 1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2

Authors: J. Hilgeman, S. Nix, A. Bartky, W. Clark, Ed..

Date: January 1995

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1747

This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment.This draft identifies managed objects for SNA Synchronous Data LinkControl (SDLC) links only.

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 1749 IEEE 802.5 Station Source Routing MIB using SMIv2

Authors: K. McCloghrie, F. Baker, E. Decker.

Date: December 1994

Formats: txt html json

Updates: RFC 1748

Status: HISTORIC

DOI: 10.17487/RFC 1749

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 by IEEE 802.5 end-stations for managing source routes on a Token Ring network where IEEE source- routing is in use. [STANDARDS-TRACK]

RFC 1750 Randomness Recommendations for Security

Authors: D. Eastlake 3rd, S. Crocker, J. Schiller.

Date: December 1994

Formats: txt html json

Obsoleted by: RFC 4086

Status: INFORMATIONAL

DOI: 10.17487/RFC 1750

Security systems today are built on increasingly strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. The sophisticated attacker of these security systems may find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the number space.
Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available. And it gives examples of how large such quantities need to be for some particular applications.

RFC 1751 A Convention for Human-Readable 128-bit Keys

Authors: D. McDonald.

Date: December 1994

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1751

This memo proposes a convention for use with Internet applications & protocols using 128-bit cryptographic keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1752 The Recommendation for the IP Next Generation Protocol

Authors: S. Bradner, A. Mankin.

Date: January 1995

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1752

This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the InternetProtocol. This recommendation was accepted by the InternetEngineering Steering Group (IESG).

RFC 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture

Authors: N. Chiappa.

Date: December 1994

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1753

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 big-internet@munnari.oz.au mailing list.
This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. Also presented is some background information, consisting of i) information about architectural and design principles which might apply to the design of a new internetworking layer, and ii) some details of the logic and reasoning behind particular requirements.

RFC 1754 IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1

Authors: M. Laubach.

Date: January 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1754

This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1755 ATM Signaling Support for IP over ATM

Authors: M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis.

Date: February 1995

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1755

This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services as specified in the ATM Forum User-Network Interface (UNI)Specification Version 3.1 [ATMF94]. IP over ATM implementations utilize the services of local ATM signaling entities to establish and release ATM connections. This memo should be used to define the support required by IP over ATM implementations from their local ATM signaling entities.
This document is an implementors guide intended to foster interoperability among RFC 1577, RFC 1483, and UNI ATM signaling. It applies to IP hosts and routers which are also ATM endsystems and assumes ATM networks that completely implement the ATM Forum UNISpecification Version 3.1. Unless explicitly stated, no distinction is made between the Private and Public UNI.
UNI 3.1 is considered an erratum to the UNI 3.0 specification. It has been produced by the ATM Forum, largely for reasons of alignment withRecommendation Q.2931. Although UNI 3.1 is based on UNI 3.0 there are several changes that make the two versions incompatible. A description of how to support IP over ATM using UNI 3.0 is found inAppendix B.

RFC 1756 Remote Write Protocol - Version 1.0

Authors: T. Rinne.

Date: January 1995

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1756

This document describes a simple Remote Write Protocol (RWP). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1757 Remote Network Monitoring Management Information Base

Authors: S. Waldbusser.

Date: February 1995

Formats: txt json html

Obsoletes: RFC 1271

Obsoleted by: RFC 2819

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1757

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring devices.

RFC 1758 NADF Standing Documents: A Brief Overview

Authors: The North American Directory Forum.

Date: February 1995

Formats: txt html json

Obsoletes: RFC 1417

Status: INFORMATIONAL

DOI: 10.17487/RFC 1758

The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1759 Printer MIB

Authors: R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog.

Date: March 1995

Formats: txt html json

Obsoleted by: RFC 3805

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1759

A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK]

RFC 1760 The S/KEY One-Time Password System

Authors: N. Haller.

Date: February 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1760

This document describes the S/KEY* One-Time Password system as released for public use by Bellcore and as described in reference[3]. A reference implementation and documentation are available by anonymous ftp from ftp.bellcore.com in the directories pub/nmh/...

RFC 1761 Snoop Version 2 Packet Capture File Format

Authors: B. Callaghan, R. Gilligan.

Date: February 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1761

This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files.

RFC 1762 The PPP DECnet Phase IV Control Protocol (DNCP)

Authors: S. Senum.

Date: March 1995

Formats: txt json html

Obsoletes: RFC 1376

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1762

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the NCP for establishing and configuringDigital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc).

RFC 1763 The PPP Banyan Vines Control Protocol (BVCP)

Authors: S. Senum.

Date: March 1995

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1763

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, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP.

RFC 1764 The PPP XNS IDP Control Protocol (XNSCP)

Authors: S. Senum.

Date: March 1995

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1764

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, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet DatagramProtocol (IDP) over PPP.

RFC 1765 OSPF Database Overflow

Authors: J. Moy.

Date: March 1995

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1765

Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. This memo details a way of gracefully handling unanticipated database overflows.
This memo is a product of the OSPF Working Group. Please send comments to ospf@gated.cornell.edu.

RFC 1766 Tags for the Identification of Languages

Authors: H. Alvestrand.

Date: March 1995

Formats: txt json html

Obsoleted by: RFC 3066, RFC 3282

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1766

This document describes a language tag for use in cases where it is desired to indicate the language used in an information object.
It also defines a Content-language: header, for use in the case where one desires to indicate the language of something that has RFC-822- like headers, like MIME body parts or Web documents, and a new parameter to the Multipart/Alternative type, to aid in the usage of the Content-Language: header.

RFC 1767 MIME Encapsulation of EDI Objects

Authors: D. Crocker.

Date: March 1995

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1767

Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]

RFC 1768 Host Group Extensions for CLNP Multicasting

Authors: D. Marlow.

Date: March 1995

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1768

This memo documents work performed in the TUBA (TCP/UDP over BiggerAddresses) working group of IPng area prior to the July 1994 decision to utilize SIPP-16 as the basis for IPng. The TUBA group worked on extending the Internet Protocol suite by the use of ISO 8473 (CLNP) and its related routing protocols. This memo describes multicast extensions to CLNP and its related routing protocols for Internet multicast use. Publication of this memo does not imply acceptance by any IETF Working Group for the ideas expressed within.
This memo provides a specification for multicast extensions to theCLNP protocol similar to those provided to IP by RFC1112. These extensions are intended to provide the mechanisms needed by a host for multicasting in a CLNP based Internet. This memo covers addressing extensions to the CLNP addressing structure, extensions to the CLNP protocol and extensions to the ES-IS protocol. An appendix discusses the differences between IP multicast and the CLNP multicast approach provided in this memo.

RFC 1769 Simple Network Time Protocol (SNTP)

Authors: D. Mills.

Date: March 1995

Formats: txt html json

Obsoletes: RFC 1361

Obsoleted by: RFC 2030, RFC 4330

Status: INFORMATIONAL

DOI: 10.17487/RFC 1769

This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It can operate in both unicast modes (point to point) and broadcast modes (point to multipoint). It can also operate in IP multicast mode where this service is available. SNTP involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
This memorandum obsoletes RFC-1361 of the same title. Its purpose is to explain the protocol model for operation in broadcast mode, to provide additional clarification in some places and to correct a few typographical errors. A working knowledge of the NTP Version 3 specification RFC-1305 is not required for an implementation of SNTP.Distribution of this memorandum is unlimited.

RFC 1770 IPv4 Option for Sender Directed Multi-Destination Delivery

Authors: C. Graff.

Date: March 1995

Formats: txt html json

Obsoleted by: RFC 6814

Status: HISTORIC

DOI: 10.17487/RFC 1770

This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed BroadcastMode (SDBM). The SDBM provides unreliable UDP delivery to a set ofIP addresses included in the option field of an IPv4 datagram. Data reliability if required will be provided by the application layer.This approach was developed to support sender directed multi- destination delivery to sparsely populated groups with no additional control traffic. This approach will find application in the extremely bandwidth constrained tactical military environment, as well as in some commercial applications requiring sender control of data delivery.

RFC 1771 A Border Gateway Protocol 4 (BGP-4)

Authors: Y. Rekhter, T. Li.

Date: March 1995

Formats: txt html json

Obsoletes: RFC 1654

Obsoleted by: RFC 4271

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1771

This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter- autonomous system routing protocol for the Internet.

RFC 1772 Application of the Border Gateway Protocol in the Internet

Authors: Y. Rekhter, P. Gross.

Date: March 1995

Formats: txt json html

Obsoletes: RFC 1655

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1772

This document, together with its companion document, "A BorderGateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4(BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.
Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net).

RFC 1773 Experience with the BGP-4 protocol

Authors: P. Traina.

Date: March 1995

Formats: txt json html

Obsoletes: RFC 1656

Status: INFORMATIONAL

DOI: 10.17487/RFC 1773

The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1774 BGP-4 Protocol Analysis

Authors: P. Traina, Ed..

Date: March 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1774

The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1775 To Be "On" the Internet

Authors: D. Crocker.

Date: March 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1775

The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet. This document suggests four terms, for distinguishing the major classes of access.

RFC 1776 The Address is the Message

Authors: S. Crocker.

Date: 1 April 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1776

Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1777 Lightweight Directory Access Protocol

Authors: W. Yeong, T. Howes, S. Kille.

Date: March 1995

Formats: txt json html

Obsoletes: RFC 1487

Obsoleted by: RFC 3494

Status: HISTORIC

DOI: 10.17487/RFC 1777

The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500Directory, and is intended to be a complement to the DAP itself.
Key aspects of LDAP are:
- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.
- Many protocol data elements are encoding as ordinary strings (e.g.,Distinguished Names).
- A lightweight BER encoding is used to encode all protocol elements.

RFC 1778 The String Representation of Standard Attribute Syntaxes

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 1779 A String Representation of Distinguished Names

Authors: S. Kille.

Date: March 1995

Formats: txt html json

Obsoletes: RFC 1485

Obsoleted by: RFC 2253, RFC 3494

Status: HISTORIC

DOI: 10.17487/RFC 1779

The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1.When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name.This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name.

RFC 1780 Internet Official Protocol Standards

Authors: J. Postel, Ed..

Date: March 1995

Formats: txt html json

Obsoletes: RFC 1720

Obsoleted by: RFC 1800

Status: HISTORIC

DOI: 10.17487/RFC 1780

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC 1781 Using the OSI Directory to Achieve User Friendly Naming

Authors: S. Kille.

Date: March 1995

Formats: txt html json

Obsoletes: RFC 1484

Obsoleted by: RFC 3494

Status: HISTORIC

DOI: 10.17487/RFC 1781

The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability
This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them.This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in [5], and it is intended that these specifications are compatible.

RFC 1782 TFTP Option Extension

Authors: G. Malkin, A. Harkin.

Date: March 1995

Formats: txt json html

Obsoleted by: RFC 2347

Updates: RFC 1350

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1782

The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.

RFC 1783 TFTP Blocksize Option

Authors: G. Malkin, A. Harkin.

Date: March 1995

Formats: txt json html

Obsoleted by: RFC 2348

Updates: RFC 1350

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1783

The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the booting of diskless nodes on a Local Area Network. TFTP is used because it is very simple to implement in a small node's limited ROM space. However, the choice of a 512-byte blocksize is not the most efficient for use on a LAN whose MTU may 1500 bytes or greater.
This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. The TFTP Option Extension mechanism is described in [2].

RFC 1784 TFTP Timeout Interval and Transfer Size Options

Authors: G. Malkin, A. Harkin.

Date: March 1995

Formats: txt html json

Obsoleted by: RFC 2349

Updates: RFC 1350

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1784

The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.
This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. The TFTP Option Extension mechanism is described in [2].
This document assumes that the reader is familiar with the terminology and notation of both [1] and [2].

RFC 1785 TFTP Option Negotiation Analysis

Authors: G. Malkin, A. Harkin.

Date: March 1995

Formats: txt html json

Updates: RFC 1350

Status: INFORMATIONAL

DOI: 10.17487/RFC 1785

The TFTP option negotiation mechanism, proposed in [1], is a backward-compatible extension to the TFTP protocol, defined in [2].It allows file transfer options to be negotiated prior to the transfer using a mechanism which is consistent with TFTP's RequestPacket format. The mechanism is kept simple by enforcing a request- respond-acknowledge sequence, similar to the lock-step approach taken by TFTP itself.
This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation.

RFC 1786 Representation of IP Routing Policies in a Routing Registry (ripe-81++)

Authors: T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, J. Yu.

Date: March 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1786

This document was originally published as a RIPE document known as ripe-181 but is also being published as an Informational RFC to reach a larger audience than its original scope. It has received community wide interest and acknowledgment throughout the Internet service provider community and will be used as the basic starting point for future work on Internet Routing Registries and routing policy representation. It can also be referred to as ripe-81++. This document is an update to the original `ripe-81'[1] proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc.[2] and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry.

RFC 1787 Routing in a Multi-provider Internet

Authors: Y. Rekhter.

Date: April 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1787

This document was prepared by the author on behalf of the InternetArchitecture Board (IAB). It is offered by the IAB to stimulate discussion.
Over the past few years the Internet has undergone significant changes. Among them is the emergence of multiple Network ServiceProviders, where resources that provide Internet-wide IP connectivity(routers, links) are controlled by different organizations. This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing.

RFC 1788 ICMP Domain Name Messages

Authors: W. Simpson.

Date: April 1995

Formats: txt html json

Obsoleted by: RFC 6918

Status: HISTORIC

DOI: 10.17487/RFC 1788

This document specifies ICMP messages for learning the FullyQualified Domain Name associated with an IP address.

RFC 1789 INETPhone: Telephone Services and Servers on Internet

Authors: C. Yang.

Date: April 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1789

INETPhone is a true telephone service through the Internet. It integrates the local telephone networks and the Internet usingINETPhone servers. Thus a long distance call can be split into two local calls and an Internet connection, which is transparent to end users. Such a phone service through Internet will be a major step towards integrated services on Internet. In order to support theINETPhone and lay down the ground rules of the service, a scheme of"open partnership" is proposed, so that the entire Internet community can have the equal opportunity and benefits from the INETPhone service.

RFC 1790 An Agreement between the Internet Society and Sun Microsystems, Inc

Authors: in the Matter of ONC RPC and XDR Protocols. V. Cerf.

Date: April 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1790

This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU

Authors: T. Sung.

Date: April 1995

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1791

TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

RFC 1792 TCP/IPX Connection Mib Specification

Authors: T. Sung.

Date: April 1995

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1792

New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

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 1794 DNS Support for Load Balancing

Authors: T. Brisco.

Date: April 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1794

This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1

Authors: L. Wells, A. Bartky, Ed..

Date: April 1995

Formats: txt html json

Obsoletes: RFC 1434

Status: INFORMATIONAL

DOI: 10.17487/RFC 1795

This RFC describes use of Data Link Switching over TCP/IP. The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and Implementers.
This RFC was created as a joint effort of the Advanced Peer-to-PeerNetworking (APPN) Implementers Workshop (AIW) Data Link Switching(DLSw) Related Interest Group (RIG). The APPN Implementers Workshop is a group sponsored by IBM and consists of representatives of member companies implementing current and future IBM Networking interoperable products. The DLSw Related Interest Group was formed in this forum in order to produce a single version of the Switch toSwitch Protocol (SSP) which could be implemented by all vendors, which would fix documentation problems with the existing RFC 1434, and which would enhance and evolve the protocol to add new functions and features.
This document is based on RFC 1434. This document contains significant changes to RFC 1434 and therefore obsoletes that document.
Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: aiw-dlsw@networking.raleigh.ibm.com.
NOTE 1: This is a widely subscribed mailing list and messages sent to this address will be sent to all members of the DLSw mailing list.For specific questions relating to subscribing to the AIW and any of it's working groups send email to: appn@vnet.ibm.com
Information regarding all of the AIW working groups and the work they are producing can be obtained by copying, via anonymous ftp, the file aiwinfo.psbin or aiwinfo.txt from the Internet host networking.raleigh.ibm.com, located in directory aiw.
NOTE 2: These mailing lists and addresses are subject to change.

RFC 1796 Not All RFCs are Standards

Authors: C. Huitema, J. Postel, S. Crocker.

Date: April 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1796

This document discusses the relationship of the Request for Comments(RFCs) notes to Internet Standards.

RFC 1797 Class A Subnet Experiment

Authors: Internet Assigned Numbers Authority (IANA).

Date: April 1995

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1797

There appears to be some interest in experimenting with subnetting the class A addresses. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

RFC 1798 Connection-less Lightweight X.500 Directory Access Protocol

Authors: A. Young.

Date: June 1995

Formats: txt html json

Obsoleted by: RFC 3352

Status: HISTORIC

DOI: 10.17487/RFC 1798

The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]

RFC 1799 Request for Comments Summary RFC Numbers 1700-1799

Authors: M. Kennedy.

Date: January 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1799

RFC 1800 Internet Official Protocol Standards

Authors: J. Postel, Ed..

Date: July 1995

Formats: txt json html

Obsoletes: RFC 1780

Obsoleted by: RFC 1880

Status: HISTORIC

DOI: 10.17487/RFC 1800

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC 1801 MHS use of the X.500 Directory to support MHS Routing

Authors: S. Kille.

Date: June 1995

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1801

The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is "nearer" to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. This memo defines an Experimental Protocol for the Internet community.

RFC 1802 Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing

Authors: H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera.

Date: June 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1802

The Internet X.400 community (i.e., GO-MHS) currently lacks a distributed mechanism providing dynamic updating and management of message routing information. The IETF MHS-DS Working Group has specified an approach for X.400 Message Handling Systems to perform message routing using OSI Directory Services. The MHS-DS approach has been successfully tested in a number of local environments.
This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale. The results of this pilot will then be used to draw up recommendations for a global deployment.

RFC 1803 Recommendations for an X.500 Production Directory Service

Authors: R. Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W. Yeong.

Date: June 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1803

This document contains a set of basic recommendations for a country- level X.500 DSA. These recommendations can only be considered a starting point in the quest to create a global production qualityX.500 infrastructure. For there to be a true "production quality"X.500 infrastructure more work must be done, including a transition from the 1988 X.500 (plus some Internet extensions) to the 1993 X.500 standard (including the '93 replication and knowledge model). This document does not discuss this transition.

RFC 1804 Schema Publishing in X.500 Directory

Authors: G. Mansfield, P. Rajeev, S. Raghavan, T. Howes.

Date: June 1995

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1804

The X.500 directory provides a powerful mechanism for storing and retrieving information about objects of interest. To interpret the information stored in the directory, the schema must be known to all the components of the directory. Presently, there are no means other than ftp to distribute schema information across the Internet. This is proving to be a severe constraint as the Directory is growing.This document presents a solution to the schema distribution problem using the existing mechanisms of the directory. A naming scheme for naming schema objects and a meta-schema for storing schema objects is presented. The procedures for fetching unknown schema from the directory at runtime are described.

RFC 1805 Location-Independent Data/Software Integrity Protocol

Authors: A. Rubin.

Date: June 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1805

This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This protocol is intended for the distribution of software, data, documents, and any other file that is subject to malicious modification. The protocol described here is intended to provide assurances of integrity and time. A trusted third party is required.

RFC 1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header

Authors: R. Troost, S. Dorner.

Date: June 1995

Formats: txt html json

Obsoleted by: RFC 2183

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1806

This memo provides a mechanism whereby messages conforming to the[RFC 1521] ("MIME") specification can convey presentational information. It specifies a new "Content-Disposition" header, optional and valid for any [RFC 1521] entity ("message" or "body part"). Two values for this header are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.
This document is intended as an extension to [RFC 1521]. As such, the reader is assumed to be familiar with [RFC 1521], and [RFC 822]. The information presented herein supplements but does not replace that found in those documents.

RFC 1807 A Format for Bibliographic Records

Authors: R. Lasher, D. Cohen.

Date: June 1995

Formats: txt html json

Obsoletes: RFC 1357

Status: INFORMATIONAL

DOI: 10.17487/RFC 1807

This RFC defines a format for bibliographic records describing technical reports. This format is used by the Cornell UniversityDienst protocol and the Stanford University SIFT system. The original RFC (RFC 1357) was written by D. Cohen, ISI, July 1992.This is a revision of RFC 1357. New fields include handle, other_access, keyword, and withdraw.

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 1809 Using the Flow Label Field in IPv6

Authors: C. Partridge.

Date: June 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1809

The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo is for information purposes only and is not one of the IPv6 specifications.Distribution of this memo is unlimited.

RFC 1810 Report on MD5 Performance

Authors: J. Touch.

Date: June 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1810

MD5 is an authentication algorithm, which has been proposed as the default authentication option in IPv6. When enabled, the MD5 algorithm operates over the entire data packet, including header.This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth.MD5 can be implemented in existing hardware technology at 256 Mbps, and in software at 87 Mbps. These rates cannot support current IP rates, e.g., 100 Mbps TCP and 130 Mbps UDP over ATM. If MD5 cannot support existing network bandwidth using existing technology, it will not scale as network speeds increase in the future. This RFC is intended to alert the IP community about the performance limitations of MD5, and to suggest that alternatives be considered for use in high speed IP implementations.

RFC 1811 U.S

Authors: Government Internet Domain Names. Federal Networking Council.

Date: June 1995

Formats: txt json html

Obsoleted by: RFC 1816

Status: INFORMATIONAL

DOI: 10.17487/RFC 1811

This document describes the registration policies for the top-level domain ".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.
As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic.

RFC 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 1813 NFS Version 3 Protocol Specification

Authors: B. Callaghan, B. Pawlowski, P. Staubach.

Date: June 1995

Formats: txt html json

Also: RFC 1094

Status: INFORMATIONAL

DOI: 10.17487/RFC 1813

This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations.

RFC 1814 Unique Addresses are Good

Authors: E. Gerich.

Date: June 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1814

The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider.

RFC 1815 Character Sets ISO-10646 and ISO-10646-J-1

Authors: M. Ohta.

Date: July 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1815

Though the ISO character set standard of ISO 10646 is specified reasonably well about European characters, it is not so useful in an fully internationalized environment.
For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary.
This memo provides information on such profiling, along with charset names to each profiled instance.
Though all the effort is done to make the resulting charset as useful10646 based charset as possible, the result is not so good. So, the charsets defined in this memo are only for reference purpose and its use for practical purpose is strongly discouraged.

RFC 1816 U.S

Authors: Government Internet Domain Names. Federal Networking Council.

Date: August 1995

Formats: txt html json

Obsoletes: RFC 1811

Obsoleted by: RFC 2146

Status: INFORMATIONAL

DOI: 10.17487/RFC 1816

This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for.GOV can be fit. This policy is exactly comparable to that for the top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.
As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic.

RFC 1817 CIDR and Classful Routing

Authors: Y. Rekhter.

Date: August 1995

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1817

Classless Inter-Domain Routing (CIDR) is used in the Internet as the primary mechanism to improve scalability of the Internet routing system. This document represents the IAB's (Internet ArchitectureBoard) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology.

RFC 1818 Best Current Practices

Authors: J. Postel, T. Li, Y. Rekhter.

Date: August 1995

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1818

This document describes a new series of documents which describe best current practices for the Internet community. Documents in this series carry the endorsement of the Internet Engineering SteeringGroup (IESG).

RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+

Authors: L. Delgrossi, Ed., L. Berger, Ed..

Date: August 1995

Formats: txt json html

Obsoletes: RFC 1190, IEN119

Status: HISTORIC

DOI: 10.17487/RFC 1819

This memo contains a revised specification of the Internet STreamProtocol Version 2 (ST2). ST2 is an experimental resource reservation protocol intended to provide end-to-end real-time guarantees over an internet. It allows applications to build multi-destination simplex data streams with a desired quality of service. The revised version of ST2 specified in this memo is called ST2+.
This specification is a product of the STream Protocol Working Group of the Internet Engineering Task Force.

RFC 1820 Multimedia E-mail (MIME) User Agent Checklist

Authors: E. Huizer.

Date: August 1995

Formats: txt json html

Obsoleted by: RFC 1844

Status: INFORMATIONAL

DOI: 10.17487/RFC 1820

This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described.

RFC 1821 Integration of Real-time Services in an IP-ATM Network Architecture

Authors: M. Borden, E. Crawley, B. Davie, S. Batsell.

Date: August 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1821

The IETF is currently developing an integrated service model which is designed to support real-time services on the Internet.Concurrently, the ATM Forum is developing Asynchronous Transfer Mode networking which similarly provides real-time networking support. The use of ATM in the Internet as a link layer protocol is already occurring, and both the IETF and the ATM Forum are producing specifications for IP over ATM. The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services.

RFC 1822 A Grant of Rights to Use a Specific IBM patent with Photuris

Authors: J. Lowe.

Date: August 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1822

This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1823 The LDAP Application Program Interface

Authors: T. Howes, M. Smith.

Date: August 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1823

This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1824 The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4)

Authors: H. Danisch.

Date: August 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1824

This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys.

RFC 1825 Security Architecture for the Internet Protocol

Authors: R. Atkinson.

Date: August 1995

Formats: txt json html

Obsoleted by: RFC 2401

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1825

This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS- TRACK]

RFC 1826 IP Authentication Header

Authors: R. Atkinson.

Date: August 1995

Formats: txt html json

Obsoleted by: RFC 2402

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1826

This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK]

RFC 1827 IP Encapsulating Security Payload (ESP)

Authors: R. Atkinson.

Date: August 1995

Formats: txt html json

Obsoleted by: RFC 2406

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1827

This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK]

RFC 1828 IP Authentication using Keyed MD5

Authors: P. Metzger, W. Simpson.

Date: August 1995

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1828

This document describes the use of keyed MD5 with the IPAuthentication Header.

RFC 1829 The ESP DES-CBC Transform

Authors: P. Karn, P. Metzger, W. Simpson.

Date: August 1995

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1829

This document describes the DES-CBC security transform for the IPEncapsulating Security Payload (ESP).

RFC 1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages

Authors: G. Vaudreuil.

Date: August 1995

Formats: txt json html

Obsoleted by: RFC 3030

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1830

This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community.

RFC 1831 RPC: Remote Procedure Call Protocol Specification Version 2

Authors: R. Srinivasan.

Date: August 1995

Formats: txt json html

Obsoleted by: RFC 5531

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1831

This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]

RFC 1832 XDR: External Data Representation Standard

Authors: R. Srinivasan.

Date: August 1995

Formats: txt html json

Obsoleted by: RFC 4506

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1832

This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [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 1834 Whois and Network Information Lookup Service, Whois++

Authors: J. Gargano, K. Weiss.

Date: August 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1834

This memo describes new features for WHOIS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1835 Architecture of the WHOIS++ service

Authors: P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider.

Date: August 1995

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1835

This document describes WHOIS++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. We describe an extension to the simple WHOIS data model and query protocol and a companion extensible, distributed indexing service. A number of options have also been added such as the use of multiple languages and character sets, more advanced search expressions, structured data and a number of other useful features. An optional authentication mechanism for protecting all or part of the associated WHOIS++ information database from unauthorized access is also described.

RFC 1836 Representing the O/R Address hierarchy in the X.500 Directory Information Tree

Authors: S. Kille.

Date: August 1995

Formats: txt html json

Obsoleted by: RFC 2294

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1836

This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This is useful for a range of purposes, including:

RFC 1837 Representing Tables and Subtrees in the X.500 Directory

Authors: S. Kille.

Date: August 1995

Formats: txt html json

Obsoleted by: RFC 2293

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1837

This document defines techniques for representing two types of information mapping in the OSI Directory [1].
1. Mapping from a key to a value (or set of values), as might be done in a table lookup.
2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree.
These techniques were developed for supporting MHS use of Directory[2], but are specified separately as they have more general applicability.

RFC 1838 Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses

Authors: S. Kille.

Date: August 1995

Formats: txt json html

Obsoleted by: RFC 2164

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1838

This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2].

RFC 1841 PPP Network Control Protocol for LAN Extension

Authors: J. Chapman, D. Coli, A. Harvey, B. Jensen, K. Rowett.

Date: September 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1841

Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informationalRFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol.

RFC 1842 ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages

Authors: Y. Wei, Y. Zhang, J. Li, J. Ding, Y. Jiang.

Date: August 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1842

This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. The 7-bit representation of GB 2312 Chinese text was specified by Fung Fung Lee of Stanford University [Lee89] and implemented in various software packages under different platforms (see appendix for a partial list of the available software packages that support this encoding method). It is further tested and used in the usenet newsgroups alt.chinese.text and chinese.* as well as various other network forums with considerable success. Future extensions of this encoding method can accommodate additional GB character sets and other east asian language character sets [Wei94].
The name given to this encoding is "HZ-GB-2312", which is intended to be used in the "charset" parameter field of MIME headers (see [MIME1] and [MIME2]).

RFC 1843 HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters

Authors: F. Lee.

Date: August 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1843

The content of this memo is identical to an article of the same title written by the author on September 4, 1989. In this memo, GB stands for GB2312-80. Note that the title is kept only for historical reasons. HZ has been widely used for purposes other than "file exchange".

RFC 1844 Multimedia E-mail (MIME) User Agent Checklist

Authors: E. Huizer.

Date: August 1995

Formats: txt html json

Obsoletes: RFC 1820

Status: INFORMATIONAL

DOI: 10.17487/RFC 1844

This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described.

RFC 1845 SMTP Service Extension for Checkpoint/Restart

Authors: D. Crocker, N. Freed, A. Cargille.

Date: September 1995

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1845

This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption.

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 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted

Authors: J. Galvin, S. Murphy, S. Crocker, N. Freed.

Date: October 1995

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1847

This document defines a framework within which security services may be applied to MIME body parts. MIME, an acronym for "MultipurposeInternet Mail Extensions", defines the format of the contents ofInternet mail messages and provides for multi-part textual and non- textual message bodies. The new content types are subtypes of multipart: signed and encrypted. Each will contain two body parts: one for the protected data and one for the control information necessary to remove the protection. The type and contents of the control information body parts are determined by the value of the protocol parameter of the enclosing multipart/signed or multipart/encrypted content type, which is required to be present.

RFC 1848 MIME Object Security Services

Authors: S. Crocker, N. Freed, J. Galvin, S. Murphy.

Date: October 1995

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1848

This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services toMIME objects. The services are offered through the use of end-to-end cryptography between an originator and a recipient at the application layer. Asymmetric (public key) cryptography is used in support of the digital signature service and encryption key management.Symmetric (secret key) cryptography is used in support of the encryption service. The procedures are intended to be compatible with a wide range of public key management approaches, including both ad hoc and certificate-based schemes. Mechanisms are provided to support many public key management approaches.

RFC 1849 "Son of 1036": News Article Format and Transmission

Authors: H. Spencer.

Date: March 2010

Formats: txt html json

Obsoleted by: RFC 5536, RFC 5537

Status: HISTORIC

DOI: 10.17487/RFC 1849

By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adoptedProposed Standards for Netnews.
It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations.

RFC 1850 OSPF Version 2 Management Information Base

Authors: F. Baker, R. Coltun.

Date: November 1995

Formats: txt html json

Obsoletes: RFC 1253

Obsoleted by: RFC 4750

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1850

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the Open Shortest PathFirst Routing Protocol.

RFC 1851 The ESP Triple DES Transform

Authors: P. Karn, P. Metzger, W. Simpson.

Date: September 1995

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1851

This document describes the Triple DES-CBC security transform for theIP Encapsulating Security Payload (ESP).

RFC 1852 IP Authentication using Keyed SHA

Authors: P. Metzger, W. Simpson.

Date: September 1995

Formats: txt json html

Obsoleted by: RFC 2841

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1852

This document describes the use of keyed SHA with the IPAuthentication Header.

RFC 1853 IP in IP Tunneling

Authors: W. Simpson.

Date: October 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1853

This document discusses implementation techniques for using IPProtocol/Payload number 4 Encapsulation for tunneling with IPSecurity and other protocols.

RFC 1854 SMTP Service Extension for Command Pipelining

Authors: N. Freed.

Date: October 1995

Formats: txt html json

Obsoleted by: RFC 2197

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1854

This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly.

RFC 1855 Netiquette Guidelines

Authors: S. Hambridge.

Date: October 1995

Formats: txt html json

Also: FYI 0028

Status: INFORMATIONAL

DOI: 10.17487/RFC 1855

This document provides a minimum set of guidelines for NetworkEtiquette (Netiquette) which organizations may take and adapt for their own use. As such, it is deliberately written in a bulleted format to make adaptation easier and to make any particular item easy(or easier) to find. It also functions as a minimum set of guidelines for individuals, both users and administrators. This memo is the product of the Responsible Use of the Network (RUN) WorkingGroup of the IETF.

RFC 1856 The Opstat Client-Server Model for Statistics Retrieval

Authors: H. Clark.

Date: September 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1856

Network administrators gather data related to the performance, utilization, usability and growth of their data network. The amount of raw data gathered is usually quite large, typically ranging somewhere between several megabytes to several gigabytes of data each month. Few (if any) tools exist today for the sharing of that raw data among network operators or between a network service provider(NSP) and its customers. This document defines a model and protocol for a set of tools which could be used by NSPs and Network OperationCenters (NOCs) to share data among themselves and with customers.

RFC 1857 A Model for Common Operational Statistics

Authors: M. Lambert.

Date: October 1995

Formats: txt json html

Obsoletes: RFC 1404

Status: INFORMATIONAL

DOI: 10.17487/RFC 1857

This memo describes a model for operational statistics in theInternet. It gives recommendations for metrics, measurements, polling periods and presentation formats and defines a format for the exchange of operational statistics.

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 1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension

Authors: Y. Pouffary.

Date: October 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1859

This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1860 Variable Length Subnet Table For IPv4

Authors: T. Pummill, B. Manning.

Date: October 1995

Formats: txt html json

Obsoleted by: RFC 1878

Status: INFORMATIONAL

DOI: 10.17487/RFC 1860

This document itemizes the potential values for IPv4 subnets.Additional information is provided for Hex and Decmial values, classfull equivalents, and number of addresses available within the indicated block. We appreciate inputs from Bruce Pinsky (cisco) andDaniel Karrenberg (RIPE).

RFC 1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced

Authors: A. Gwinn.

Date: October 1995

Formats: txt html json

Obsoletes: RFC 1645

Status: INFORMATIONAL

DOI: 10.17487/RFC 1861

This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. In its simplest form, SNPP provides a simple way to implement a "shim" between theInternet and a TAP/IXO paging terminal. In its level 3 form, it provides an easy-to-use (and build) method for communicating and receiving end-to-end acknowledgments and replies from two-way messaging devices (such as ReFLEX units).
Gateways supporting this protocol, as well as SMTP, have been in use for well over a year at several commercial paging companies, and private businesses. Client software supporting this protocol has become widespread, and is being integrated into many of the new paging and messaging products being built. In addition to commercial software, email filters and SNPP client software for Unix and Windows(WikiPage) are available at no cost. Please contact the author for more information.
Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below.

RFC 1862 Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994

Authors: M. McCahill, J. Romkey, M. Schwartz, K. Sollins, T. Verschuren, C. Weider.

Date: November 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1862

This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet.

RFC 1863 A BGP/IDRP Route Server alternative to a full mesh routing

Authors: D. Haskin.

Date: October 1995

Formats: txt json html

Obsoleted by: RFC 4223

Status: HISTORIC

DOI: 10.17487/RFC 1863

This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers.
The intention of the proposed technique is to reduce overhead and management complexity of maintaining numerous direct BGP/IDRP sessions which otherwise might be required or desired among routers within a single routing domain as well as among routers in different domains that are connected to a common switched fabric (e.g. an ATM cloud).

RFC 1864 The Content-MD5 Header Field

Authors: J. Myers, M. Rose.

Date: October 1995

Formats: txt html json

Obsoletes: RFC 1544

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1864

This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages.

RFC 1865 EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet

Authors: W. Houser, J. Griffin, C. Hage.

Date: January 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1865

This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers. The memo introduces the Internet and assumes a basic knowledge of EDI.

RFC 1866 Hypertext Markup Language - 2.0

Authors: T. Berners-Lee, D. Connolly.

Date: November 1995

Formats: txt json html

Obsoleted by: RFC 2854

Status: HISTORIC

DOI: 10.17487/RFC 1866

The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.
HTML has been in use by the World Wide Web (WWW) global information initiative since 1990. This specification roughly corresponds to the capabilities of HTML in common use prior to June 1994. HTML is an application of ISO Standard 8879:1986 Information Processing Text andOffice Systems; Standard Generalized Markup Language (SGML).
The "text/html" Internet Media Type (RFC 1590) and MIME Content Type(RFC 1521) is defined by this specification.

RFC 1867 Form-based File Upload in HTML

Authors: E. Nebel, L. Masinter.

Date: November 1995

Formats: txt json html

Obsoleted by: RFC 2854

Status: HISTORIC

DOI: 10.17487/RFC 1867

Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community.

RFC 1868 ARP Extension - UNARP

Authors: G. Malkin.

Date: November 1995

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1868

The Address Resolution Protocol allows an IP node to determine the hardware (datalink) address of a neighboring node on a broadcast network. The protocol depends on timers to age away old ARP entries.This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly.

RFC 1869 SMTP Service Extensions

Authors: J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker.

Date: November 1995

Formats: txt html json

Obsoletes: RFC 1651

Obsoleted by: RFC 2821

Also: STD 0010

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1869

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

RFC 1870 SMTP Service Extension for Message Size Declaration

Authors: J. Klensin, N. Freed, K. Moore.

Date: November 1995

Formats: txt html json

Obsoletes: RFC 1653

Also: STD 0010

Status: INTERNET STANDARD

DOI: 10.17487/RFC 1870

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

RFC 1871 Addendum to RFC 1602 -- Variance Procedure

Authors: J. Postel.

Date: November 1995

Formats: txt html json

Obsoleted by: RFC 2026

Updates: RFC 1602, RFC 1603

Status: HISTORIC

DOI: 10.17487/RFC 1871

This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This is a modification to the procedures of RFC 1602 and 1603.

RFC 1872 The MIME Multipart/Related Content-type

Authors: E. Levinson.

Date: December 1995

Formats: txt json html

Obsoleted by: RFC 2112

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1872

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use.

RFC 1873 Message/External-Body Content-ID Access Type

Authors: E. Levinson.

Date: December 1995

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1873

When using MIME [MIME] to encapsulate a structured object that consist of many elements, for example an SGML [SGML] document, a single element may occur several times. An encapsulation normally maps each of the structured objects elements to a MIME entity. It is useful to include elements that occur multiple time exactly once. To accomplish that and to preserve the object structure it is desirable to unambiguously refer to another body part of the same message.
The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message.

RFC 1874 SGML Media Types

Authors: E. Levinson.

Date: December 1995

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1874

This document proposes new media sub-types of Text/SGML andApplication/SGML. These media types can be used in the exchange ofSGML documents and their entities. Specific details for the exchange or encapsulation of groups of related SGML entities using MIME are currently being considered by the mimesgml Working Group <sgml- internet@ebt.com&rt;.

RFC 1875 UNINETT PCA Policy Statements

Authors: N. Berge.

Date: December 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1875

This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1876 A Means for Expressing Location Information in the Domain Name System

Authors: C. Davis, P. Vixie, T. Goodwin, I. Dickinson.

Date: January 1996

Formats: txt json html

Updates: RFC 1034, RFC 1035

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1876

This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. This memo defines an Experimental Protocol for the Internet community.

RFC 1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses

Authors: S. Cobb.

Date: December 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1877

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 and a family of NetworkControl Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document extends the NCP for establishing and configuring theInternet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server(NBNS) [4] addresses.

RFC 1878 Variable Length Subnet Table For IPv4

Authors: T. Pummill, B. Manning.

Date: December 1995

Formats: txt html json

Obsoletes: RFC 1860

Status: HISTORIC

DOI: 10.17487/RFC 1878

This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table. This table includes subnetting for Class A, B, and C networks, as well as Network IDs, host ranges and IP broadcast addresses with emphasis on Class C subnets.
This memo is intended as an informational companion to Subneting RFC[1] and the Hosts Requirements RFC [2].

RFC 1879 Class A Subnet Experiment Results and Recommendations

Authors: B. Manning, Ed..

Date: January 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1879

This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1880 Internet Official Protocol Standards

Authors: J. Postel, Ed..

Date: November 1995

Formats: txt html json

Obsoletes: RFC 1800

Obsoleted by: RFC 1920

Status: HISTORIC

DOI: 10.17487/RFC 1880

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC 1881 IPv6 Address Allocation Management

Authors: IAB, IESG.

Date: December 1995

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1881

The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries.

RFC 1882 The 12-Days of Technology Before Christmas

Authors: B. Hancock.

Date: December 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1882

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1883 Internet Protocol, Version 6 (IPv6) Specification

Authors: S. Deering, R. Hinden.

Date: December 1995

Formats: txt json html

Obsoleted by: RFC 2460

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1883

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.

RFC 1884 IP Version 6 Addressing Architecture

Authors: R. Hinden, Ed., S. Deering, Ed..

Date: December 1995

Formats: txt html json

Obsoleted by: RFC 2373

Status: HISTORIC

DOI: 10.17487/RFC 1884

This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 nodes required addresses.

RFC 1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)

Authors: A. Conta, S. Deering.

Date: December 1995

Formats: txt html json

Obsoleted by: RFC 2463

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1885

This document specifies a set of Internet Control Message Protocol(ICMP) messages for use with version 6 of the Internet Protocol(IPv6). The Internet Group Management Protocol (IGMP) messages specified in STD 5, RFC 1112 have been merged into ICMP, for IPv6, and are included in this document.

RFC 1886 DNS Extensions to support IP version 6

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 1887 An Architecture for IPv6 Unicast Address Allocation

Authors: Y. Rekhter, Ed., T. Li, Ed..

Date: December 1995

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1887

This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. The overall IPv6 addressing architecture is defined in [2]. This document does not go into the details of an addressing plan.

RFC 1888 OSI NSAPs and IPv6

Authors: J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd.

Date: August 1996

Formats: txt html json

Obsoleted by: RFC 4048

Updated by: RFC 4548

Status: HISTORIC

DOI: 10.17487/RFC 1888

This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required.

RFC 1889 RTP: A Transport Protocol for Real-Time Applications

Authors: Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson.

Date: January 1996

Formats: txt html json

Obsoleted by: RFC 3550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1889

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.

RFC 1890 RTP Profile for Audio and Video Conferences with Minimal Control

Authors: Audio-Video Transport Working Group, H. Schulzrinne.

Date: January 1996

Formats: txt html json

Obsoleted by: RFC 3551

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1890

This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.
The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.

RFC 1891 SMTP Service Extension for Delivery Status Notifications

Authors: K. Moore.

Date: January 1996

Formats: txt html json

Obsoleted by: RFC 3461

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1891

This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

RFC 1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages

Authors: G. Vaudreuil.

Date: January 1996

Formats: txt json html

Obsoleted by: RFC 3462

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1892

The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK]

RFC 1893 Enhanced Mail System Status Codes

Authors: G. Vaudreuil.

Date: January 1996

Formats: txt json html

Obsoleted by: RFC 3463

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1893

There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK]

RFC 1894 An Extensible Message Format for Delivery Status Notifications

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 1895 The Application/CALS-1840 Content-type

Authors: E. Levinson.

Date: February 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1895

This memorandum provides guidelines for using the United StatesDepartment of Defense Military Standard MIL-STD-1840, "AutomatedInterchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521. Electronic mail provides a more convenient mechanism that delivery via physical media for certain types and quantities of data. Software already exists to support data exchanges based on MIL-STD-1840 and it can continue to be used in conjunction with electronic mail exchanges defined in this document. This document defines a new media type and a MIME message structure for exchanging data in conformance with MIL-STD-1840.

RFC 1896 The text/enriched MIME Content-type

Authors: P. Resnick, A. Walker.

Date: February 1996

Formats: txt json ps html

Obsoletes: RFC 1523, RFC 1563

Status: INFORMATIONAL

DOI: 10.17487/RFC 1896

MIME [RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enrichedMIME type. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This document is only a minor revision to the text/enriched MIME type that was first described in[RFC-1523] and [RFC-1563], and is only intended to be used in the short term until other MIME types for text formatting in Internet mail are developed and deployed.

RFC 1897 IPv6 Testing Address Allocation

Authors: R. Hinden, J. Postel.

Date: January 1996

Formats: txt json html

Obsoleted by: RFC 2471

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1897

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community.

RFC 1898 CyberCash Credit Card Protocol Version 0.8

Authors: D. Eastlake 3rd, B. Boesch, S. Crocker, M. Yesil.

Date: February 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1898

CyberCash is developing a general payments system for use over theInternet. The structure and communications protocols of version 0.8 are described. This version includes credit card payments only.Additional capabilities are planned for future versions.
This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area ofInternet payments. CyberCash is committed to the further development of its system and to cooperation with the Internet Engineering TaskForce and other standards organizations.

RFC 1899 Request for Comments Summary RFC Numbers 1800-1899

Authors: J. Elliott.

Date: January 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1899

RFC 1900 Renumbering Needs Work

Authors: B. Carpenter, Y. Rekhter.

Date: February 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1900

Renumbering, i.e., changes in the IP addressing information of various network components, is likely to become more and more widespread and common. The Internet Architecture Board (IAB) would like to stress the need to develop and deploy solutions that would facilitate such changes.

RFC 1901 Introduction to Community-based SNMPv2

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: January 1996

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1901

The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2). This document specifies an Experimental protocol for the Internet community.

RFC 1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: January 1996

Formats: txt json html

Obsoletes: RFC 1442

Obsoleted by: RFC 2578

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1902

It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]

RFC 1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: January 1996

Formats: txt json html

Obsoletes: RFC 1443

Obsoleted by: RFC 2579

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1903

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

RFC 1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: January 1996

Formats: txt html json

Obsoletes: RFC 1444

Obsoleted by: RFC 2580

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1904

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

RFC 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: January 1996

Formats: txt html json

Obsoletes: RFC 1448

Obsoleted by: RFC 3416

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1905

It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]

RFC 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: January 1996

Formats: txt json html

Obsoletes: RFC 1449

Obsoleted by: RFC 3417

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1906

It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]

RFC 1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: January 1996

Formats: txt json html

Obsoletes: RFC 1450

Obsoleted by: RFC 3418

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1907

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]

RFC 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework

Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser.

Date: January 1996

Formats: txt html json

Obsoletes: RFC 1452

Obsoleted by: RFC 2576

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1908

The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1>. [STANDARDS-TRACK]

RFC 1909 An Administrative Infrastructure for SNMPv2

Authors: K. McCloghrie, Ed..

Date: February 1996

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1909

It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. This memo defines an Experimental Protocol for the Internet community.

RFC 1910 User-based Security Model for SNMPv2

Authors: G. Waters, Ed..

Date: February 1996

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1910

In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This memo defines an Experimental Protocol for the Internet community.

RFC 1911 Voice Profile for Internet Mail

Authors: G. Vaudreuil.

Date: February 1996

Formats: txt html json

Obsoleted by: RFC 2421, RFC 2422, RFC 2423

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1911

The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community.

RFC 1912 Common DNS Operational and Configuration Errors

Authors: D. Barr.

Date: February 1996

Formats: txt json html

Obsoletes: RFC 1537

Status: INFORMATIONAL

DOI: 10.17487/RFC 1912

This memo describes errors often found in both the operation ofDomain Name System (DNS) servers, and in the data that these DNS servers contain. This memo tries to summarize current Internet requirements as well as common practice in the operation and configuration of the DNS. This memo also tries to summarize or expand upon issues raised in [RFC 1537].

RFC 1913 Architecture of the Whois++ Index Service

Authors: C. Weider, J. Fullton, S. Spero.

Date: February 1996

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 1913

The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol.

RFC 1914 How to Interact with a Whois++ Mesh

Authors: P. Faltstrom, R. Schoultz, C. Weider.

Date: February 1996

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 1914

In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK]

RFC 1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol

Authors: F. Kastenholz.

Date: February 1996

Formats: txt html json

Also: BCP 0003

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 1915

The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC 1916 Enterprise Renumbering: Experience and Information Solicitation

Authors: H. Berkowitz, P. Ferguson, W. Leland, P. Nesser.

Date: February 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1916

Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. To this end the working group is soliciting information from organizations that already have gone through, or are in the process of going through, renumbering efforts. Case studies, tools, and lists of applications that require special attention are sought.

RFC 1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA

Authors: P. Nesser II.

Date: February 1996

Formats: txt json html

Also: BCP 0004

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 1917

This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to theInternet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. Similarly an appeal is issued to providers to return unused prefixes which fall outside their customary address blocks to the IANA for reapportionment.

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 1919 Classical versus Transparent IP Proxies

Authors: M. Chatel.

Date: March 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1919

Many modern IP security systems (also called "firewalls" in the trade) make use of proxy technology to achieve access control. This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems.

RFC 1920 Internet Official Protocol Standards

Authors: J. Postel.

Date: March 1996

Formats: txt html json

Obsoletes: RFC 1880

Obsoleted by: RFC 2000

Status: HISTORIC

DOI: 10.17487/RFC 1920

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC 1921 TNVIP Protocol

Authors: J. Dujonc.

Date: March 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1921

The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network.

RFC 1922 Chinese Character Encoding for Internet Messages

Authors: HF. Zhu, DY. Hu, ZG. Wang, TC. Kao, WCH. Chang, M. Crispin.

Date: March 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1922

This memo describes methods of transporting Chinese characters inInternet services which transport text, such as electronic mail[RFC-822], network news [RFC-1036], telnet [RFC-854] and the WorldWide Web [RFC-1866].

RFC 1923 RIPv1 Applicability Statement for Historic Status

Authors: J. Halpern, S. Bradner.

Date: March 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1923

RIP Version 1 [RFC-1058] has been declared an historic document.This Applicability statement provides the supporting motivation for that declaration. The primary reason, as described below, is theClassful nature of RIPv1.

RFC 1924 A Compact Representation of IPv6 Addresses

Authors: R. Elz.

Date: 1 April 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1924

This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1925 The Twelve Networking Truths

Authors: R. Callon.

Date: 1 April 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1925

This memo documents the fundamental truths of networking for theInternet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths.

RFC 1926 An Experimental Encapsulation of IP Datagrams on Top of ATM

Authors: J. Eriksson.

Date: 1 April 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1926

This RFC describes a method of encapsulating IP datagrams on top ofAcoustical Transmission Media (ATM). This is a non-recommended standard. Distribution of this memo is unnecessary.

RFC 1927 Suggested Additional MIME Types for Associating Documents

Authors: C. Rogers.

Date: 1 April 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1927

Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1928 SOCKS Protocol Version 5

Authors: M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones.

Date: March 1996

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1928

This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]

RFC 1929 Username/Password Authentication for SOCKS V5

Authors: M. Leech.

Date: March 1996

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1929

The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]

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 1931 Dynamic RARP Extensions for Automatic Network Address Acquisition

Authors: D. Brownell.

Date: April 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1931

This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP). This memo provides information for the Internet community. This memo does not define an Internet standard of any kind.

RFC 1932 IP over ATM: A Framework Document

Authors: R. Cole, D. Shur, C. Villamizar.

Date: April 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1932

It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1933 Transition Mechanisms for IPv6 Hosts and Routers

Authors: R. Gilligan, E. Nordmark.

Date: April 1996

Formats: txt json html

Obsoleted by: RFC 2893

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1933

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6.

RFC 1934 Ascend's Multilink Protocol Plus (MP+)

Authors: K. Smith.

Date: April 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1934

This document proposes an extension to the PPP Multilink Protocol(MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP.

RFC 1935 What is the Internet, Anyway?

Authors: J. Quarterman, S. Carl-Mitchell.

Date: April 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1935

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1936 Implementing the Internet Checksum in Hardware

Authors: J. Touch, B. Parham.

Date: April 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1936

This memo presents a techniques for efficiently implementing theInternet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps.

RFC 1937 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks

Authors: Y. Rekhter, D. Kandlur.

Date: May 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1937

The IP architecture assumes that each Data Link subnetwork is labeled with a single IP subnet number. A pair of hosts with the same subnet number communicate directly (with no routers); a pair of hosts with different subnet numbers always communicate through one or more routers. As indicated in RFC1620, these assumptions may be too restrictive for large data networks, and specifically for networks based on switched virtual circuit (SVC) based technologies (e.g. ATM,Frame Relay, X.25), as these assumptions impose constraints on communication among hosts and routers through a network. The restrictions may preclude full utilization of the capabilities provided by the underlying SVC-based Data Link subnetwork. This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks.

RFC 1938 A One-Time Password System

Authors: N. Haller, C. Metz.

Date: May 1996

Formats: txt html json

Obsoleted by: RFC 2289

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1938

This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]

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 1940 Source Demand Routing: Packet Format and Forwarding Specification (Version 1)

Authors: D. Estrin, T. Li, Y. Rekhter, K. Varadhan, D. Zappala.

Date: May 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1940

The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1941 Frequently Asked Questions for Schools

Authors: J. Sellers, J. Robichaux.

Date: May 1996

Formats: txt json html

Obsoletes: RFC 1578

Also: FYI 0022

Status: INFORMATIONAL

DOI: 10.17487/RFC 1941

The goal of this FYI document, produced by the Internet SchoolNetworking (ISN) group in the User Services Area of the InternetEngineering Task Force (IETF), is to act as an introduction to theInternet for faculty, administration, and other school personnel in primary and secondary schools. The intended audience is educators who are recently connected to the Internet, who are accessing theInternet by some means other than a direct connection, or who are just beginning to consider Internet access as a resource for their schools. Although the Internet Engineering Task Force is an international organization and this paper will be valuable to educators in many countries, it is limited in focus to internetworking in the United States.

RFC 1942 HTML Tables

Authors: D. Raggett.

Date: May 1996

Formats: txt html json

Obsoleted by: RFC 2854

Status: HISTORIC

DOI: 10.17487/RFC 1942

The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to support a wide variety of tables. The model is designed to work well with associated style sheets, but does not require them. It also supports rendering to braille, or speech, and exchange of tabular data with databases and spreadsheets. The HTML table model embodies certain aspects of the CALS table model, e.g. the ability to group table rows into thead, tbody and tfoot sections, plus the ability to specify cell alignment compactly for sets of cells according to the context.

RFC 1943 Building an X.500 Directory Service in the US

Authors: B. Jennings.

Date: May 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1943

This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the UnitedStates. This project is the work performed for the IntegratedDirectory Services Working Group within the Internet Engineering TaskForce, for establishing an electronic White Pages Directory Service within an organization in the US and for connecting it to a wide-areaDirectory infrastructure.
Establishing a successful White Pages Directory Service within an organization requires a collaborative effort between the technical, legal and data management components of an organization. It also helps if there is a strong commitment from the higher management to participate in a wide-area Directory Service.
The recommendations presented in the document are the result of experience from participating in the Internet White Pages project.

RFC 1944 Benchmarking Methodology for Network Interconnect Devices

Authors: S. Bradner, J. McQuaid.

Date: May 1996

Formats: txt json html

Obsoleted by: RFC 2544

Status: INFORMATIONAL

DOI: 10.17487/RFC 1944

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 1945 Hypertext Transfer Protocol -- HTTP/1.0

Authors: T. Berners-Lee, R. Fielding, H. Frystyk.

Date: May 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1945

The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature ofHTTP is the typing 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 reflects common usage of the protocol referred to as "HTTP/1.0".

RFC 1946 Native ATM Support for ST2+

Authors: S. Jackowski.

Date: May 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1946

As the demand for networked realtime services grows, so does the need for shared networks to provide deterministic delivery services. Such deterministic delivery services demand that both the source application and the network infrastructure have capabilities to request, setup, and enforce the delivery of the data. Collectively these services are referred to as bandwidth reservation and Quality of Service (QoS).
The IETF is currently working on an integrated services model to support realtime services on the Internet The IETF has not yet focused on the integration of ATM and its inherent QoS and bandwidth allocation mechanisms for delivery of realtime traffic over shared wires. (ATM hardware and interfaces provide the network infrastructure for the determinitic data delivery, however the host resident protocol stacks and applications need more attention.)
Current IETF efforts underway in the IP over ATM (ipatm) working group rely on intserv, rsvp and ST2 to address QoS issues for ATM. As such, RFC 1577 and the ATM Forum's Lan Emulation do not provide direct QoS and bandwidth allocation capabilities to network applications. Without providing a mapping of reservations-style QoS to ATM signalling, ATM will remain a 'wire' rather than a shared media infrastructure component.
This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments:
- ATM to internet,- internet to ATM, and- internet to internet across ATM.

RFC 1947 Greek Character Encoding for Electronic Mail Messages

Authors: D. Spinellis.

Date: May 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1947

This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1948 Defending Against Sequence Number Attacks

Authors: S. Bellovin.

Date: May 1996

Formats: txt json html

Obsoleted by: RFC 6528

Status: INFORMATIONAL

DOI: 10.17487/RFC 1948

IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks.

RFC 1949 Scalable Multicast Key Distribution

Authors: A. Ballardie.

Date: May 1996

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1949

The benefits of multicasting are becoming ever-more apparent, and its use much more widespread. This is evident from the growth of theMBONE [1]. Providing security services for multicast, such as traffic integrity, authentication, and confidentiality, is particularly problematic since it requires securely distributing a group (session) key to each of a group's receivers. Traditionally, the key distribution function has been assigned to a central network entity, or Key Distribution Centre (KDC), but this method does not scale for wide-area multicasting, where group members may be widely-distributed across the internetwork, and a wide-area group may be densely populated.
Even more problematic is the scalable distribution of sender-specific keys. Sender-specific keys are required if data traffic is to be authenticated on a per-sender basis.
This memo provides a scalable solution to the multicast key distribution problem.
NOTE: this proposal requires some simple support mechanisms, which, it is recommended here, be integrated into version 3 of IGMP. This support is described in Appendix B.

RFC 1950 ZLIB Compressed Data Format Specification version 3.3

Authors: P. Deutsch, J-L. Gailly.

Date: May 1996

Formats: txt json ps pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1950

This specification defines a lossless compressed data format. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format presently uses the DEFLATE compression method but can be easily extended to use other compression methods. It can be implemented readily in a manner not covered by patents. This specification also defines the ADLER-32 checksum (an extension and improvement of the Fletcher checksum), used for detection of data corruption, and provides an algorithm for computing it.

RFC 1951 DEFLATE Compressed Data Format Specification version 1.3

Authors: P. Deutsch.

Date: May 1996

Formats: txt json ps html pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 1951

This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format can be implemented readily in a manner not covered by patents.

RFC 1952 GZIP file format specification version 4.3

Authors: P. Deutsch.

Date: May 1996

Formats: txt html ps pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1952

This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. The format includes a cyclic redundancy check value for detecting data corruption. The format presently uses the DEFLATE method of compression but can be easily extended to use other compression methods. The format can be implemented readily in a manner not covered by patents.

RFC 1953 Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0

Authors: P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall.

Date: May 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1953

The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. The label allows more efficient access to cached routing information for that flow. The label can also enable a node to switch further packets belonging to the specified flow at layer 2 rather than forwarding them at layer 3.

RFC 1954 Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0

Authors: P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall.

Date: May 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1954

This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP].

RFC 1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG

Authors: R. Hinden.

Date: June 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1955

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 big-internet@munnari.oz.au mailing list.
This memo describes a proposal made to to the Routing and Addressing group [ROAD] January 1992 by Robert Hinden. It was originally sent as an email message. It proposes a medium term solution to theInternet's routing and addressing problems.

RFC 1956 Registration in the MIL Domain

Authors: D. Engebretson, R. Plzak.

Date: June 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1956

This RFC describes the policy for the registration of second level domains under the ".MIL" domain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1957 Some Observations on Implementations of the Post Office Protocol (POP3)

Authors: R. Nelson.

Date: June 1996

Formats: txt html json

Updates: RFC 1939

Status: INFORMATIONAL

DOI: 10.17487/RFC 1957

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

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 1959 An LDAP URL Format

Authors: T. Howes, M. Smith.

Date: June 1996

Formats: txt json html

Obsoleted by: RFC 2255

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1959

This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK]

RFC 1960 A String Representation of LDAP Search Filters

Authors: T. Howes.

Date: June 1996

Formats: txt json html

Obsoletes: RFC 1558

Obsoleted by: RFC 2254

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1960

The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]

RFC 1961 GSS-API Authentication Method for SOCKS Version 5

Authors: P. McMahon.

Date: June 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1961

This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK]

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 1963 PPP Serial Data Transport Protocol (SDTP)

Authors: K. Schneider, S. Venters.

Date: August 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1963

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, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This protocol was developed for the purpose of using PPP's many features to provide a standard method for synchronous data compression. The encapsulation uses a header structure based on that of the ITU-T Recommendation V.120 [2].

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 1965 Autonomous System Confederations for BGP

Authors: P. Traina.

Date: June 1996

Formats: txt json html

Obsoleted by: RFC 3065

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1965

Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP networks.
This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation.
The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.
The extension this document describes is widely deployed in theInternet today.

RFC 1966 BGP Route Reflection An alternative to full mesh IBGP

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 1967 PPP LZS-DCP Compression Protocol (LZS-DCP)

Authors: K. Schneider, R. Friend.

Date: August 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1967

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This protocol is an enhanced version of the non-DCP(Option 17) PPP Stac LZS compression protocol [5], and will be referred to as the LZS-DCP Compression Protocol.

RFC 1968 The PPP Encryption Control Protocol (ECP)

Authors: G. Meyer.

Date: June 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1968

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 encryption overPPP links.

RFC 1969 The PPP DES Encryption Protocol (DESE)

Authors: K. Sklower, G. Meyer.

Date: June 1996

Formats: txt json html

Obsoleted by: RFC 2419

Status: INFORMATIONAL

DOI: 10.17487/RFC 1969

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets.

RFC 1970 Neighbor Discovery for IP Version 6 (IPv6)

Authors: T. Narten, E. Nordmark, W. Simpson.

Date: August 1996

Formats: txt json html

Obsoleted by: RFC 2461

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1970

This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors.

RFC 1971 IPv6 Stateless Address Autoconfiguration

Authors: S. Thomson, T. Narten.

Date: August 1996

Formats: txt json html

Obsoleted by: RFC 2462

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1971

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere.

RFC 1972 A Method for the Transmission of IPv6 Packets over Ethernet Networks

Authors: M. Crawford.

Date: August 1996

Formats: txt html json

Obsoleted by: RFC 2464

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1972

This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]

RFC 1973 PPP in Frame Relay

Authors: W. Simpson.

Date: June 1996

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1973

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of Frame Relay for framing PPP encapsulated packets.

RFC 1974 PPP Stac LZS Compression Protocol

Authors: R. Friend, W. Simpson.

Date: August 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1974

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets.

RFC 1975 PPP Magnalink Variable Resource Compression

Authors: D. Schremp, J. Black, J. Weiss.

Date: August 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1975

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating multiple protocol datagrams over point-to-point links.The PPP Compression Control Protocol [2] provides a method for negotiating data compression over PPP links.
The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources.

RFC 1976 PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)

Authors: K. Schneider, S. Venters.

Date: August 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1976

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, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a standard method for encapsulating and transporting serial data over aPPP link. The PPP Compression Control Protocol [3] provides a standard method for selecting and using a compression protocol to provide for data compression on a PPP link.
This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-TerminatingEquipment (DCE).

RFC 1977 PPP BSD Compression Protocol

Authors: V. Schryver.

Date: August 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1977

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets.

RFC 1978 PPP Predictor Compression Protocol

Authors: D. Rand.

Date: August 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1978

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating multiple protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method for transporting multi-protocol datagrams over PPP encapsulated links.
This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets.

RFC 1979 PPP Deflate Protocol

Authors: J. Woods.

Date: August 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1979

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets.

RFC 1980 A Proposed Extension to HTML : Client-Side Image Maps

Authors: J. Seidman.

Date: August 1996

Formats: txt json html

Obsoleted by: RFC 2854

Status: HISTORIC

DOI: 10.17487/RFC 1980

The markup language known as "HTML/2.0" provides for image maps.Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified byUniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as "Client-Side Image Maps," which resolves these limitations.

RFC 1981 Path MTU Discovery for IP version 6

Authors: J. McCann, S. Deering, J. Mogul.

Date: August 1996

Formats: txt json html

Obsoleted by: RFC 8201

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1981

This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery forIP version 4.

RFC 1982 Serial Number Arithmetic

Authors: R. Elz, R. Bush.

Date: August 1996

Formats: txt html json

Updates: RFC 1034, RFC 1035

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1982

This memo defines serial number arithmetic, as used in the DomainName System. The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in anIETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035.

RFC 1983 Internet Users' Glossary

Authors: G. Malkin, Ed..

Date: August 1996

Formats: txt html json

Obsoletes: RFC 1392

Also: FYI 0018

Status: INFORMATIONAL

DOI: 10.17487/RFC 1983

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them.

RFC 1984 IAB and IESG Statement on Cryptographic Technology and the Internet

Authors: IAB, IESG.

Date: August 1996

Formats: txt json html

Also: BCP 0200

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 1984

The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1985 SMTP Service Extension for Remote Message Queue Starting

Authors: J. De Winter.

Date: August 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1985

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. This extension is meant to be used in startup conditions as well as for mail nodes that have transient connections to their service providers.

RFC 1986 Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)

Authors: W. Polites, W. Wollman, D. Woo, R. Langan.

Date: August 1996

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 1986

This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community.

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 1988 Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework

Authors: G. McAnally, D. Gilbert, J. Flick.

Date: August 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1988

This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1989 PPP Link Quality Monitoring

Authors: W. Simpson.

Date: August 1996

Formats: txt json html

Obsoletes: RFC 1333

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1989

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 a Quality Protocol for continuous monitoring of the viability of the link.
This document defines a protocol for generating Link-Quality-Reports.

RFC 1990 The PPP Multilink Protocol (MP)

Authors: K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti.

Date: August 1996

Formats: txt json html

Obsoletes: RFC 1717

Status: DRAFT STANDARD

DOI: 10.17487/RFC 1990

This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links. This is accomplished by means of new PPP [2] options and protocols.
The differences between the current PPP Multilink specification (RFC1717) and this memo are explained in Section 11. Any system implementing the additional restrictions required by this memo will be backwards compatible with conforming RFC 1717 implementations.

RFC 1991 PGP Message Exchange Formats

Authors: D. Atkins, W. Stallings, P. Zimmermann.

Date: August 1996

Formats: txt json html

Obsoleted by: RFC 4880

Status: INFORMATIONAL

DOI: 10.17487/RFC 1991

This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 1992 The Nimrod Routing Architecture

Authors: I. Castineyra, N. Chiappa, M. Steenstrup.

Date: August 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1992

We present a scalable internetwork routing architecture, calledNimrod. The Nimrod architecture is designed to accommodate a dynamic internetwork of arbitrary size with heterogeneous service requirements and restrictions and to admit incremental deployment throughout an internetwork. The key to Nimrod's scalability is its ability to represent and manipulate routing-related information at multiple levels of abstraction.

RFC 1993 PPP Gandalf FZA Compression Protocol

Authors: A. Barbir, D. Carr, W. Simpson.

Date: August 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 1993

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets.

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 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)

Authors: P. Vixie.

Date: August 1996

Formats: txt html json

Updates: RFC 1035

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 1996

This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data.

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 1998 An Application of the BGP Community Attribute in Multi-home Routing

Authors: E. Chen, T. Bates.

Date: August 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1998

This document presents an application of the BGP community attribute[2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet. It shows how the community based configuration can be used to replace the AS-based customization of the BGP "LOCAL_PREF" attribute, a common method used today. Not only does the technique presented simplifies configuration and management at the provider level, it also represents a paradigm shift in that it gives the potential for the customer to control its own routing policy with respect to its service provider, as well as providing the ability for policy configuration to be done at a prefix based granularity rather than the more common AS based granularity.

RFC 1999 Request for Comments Summary RFC Numbers 1900-1999

Authors: J. Elliott.

Date: January 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 1999

RFC 2000 Internet Official Protocol Standards

Authors: J. Postel, Ed..

Date: February 1997

Formats: txt json html

Obsoletes: RFC 1920

Obsoleted by: RFC 2200

Status: HISTORIC

DOI: 10.17487/RFC 2000

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard.

RFC 2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms

Authors: W. Stevens.

Date: January 1997

Formats: txt json html

Obsoleted by: RFC 2581

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2001

Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [2] and [3] provide some details on these algorithms, [4] provides examples of the algorithms in action, and [5] provides the source code for the 4.4BSD implementation. RFC 1122 requires that a TCP must implement slow start and congestion avoidance (Section 4.2.2.15 of [1]), citing [2] as the reference, but fast retransmit and fast recovery were implemented after RFC 1122. The purpose of this document is to document these four algorithms for the Internet.

RFC 2002 IP Mobility Support

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 2004 Minimal Encapsulation within IP

Authors: C. Perkins.

Date: October 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2004

This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated 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) IP Destination Address field in the original IP header. Encapsulation may be serve a variety of purposes, such as delivery of a datagram to a mobile node usingMobile IP.

RFC 2005 Applicability Statement for IP Mobility Support

Authors: J. Solomon.

Date: October 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2005

As required by [RFC 1264], this report discusses the applicability ofMobile IP to provide host mobility in the Internet. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied.

RFC 2006 The Definitions of Managed Objects for IP Mobility Support using SMIv2

Authors: D. Cong, M. Hamlen, C. Perkins.

Date: October 1996

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2006

This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the MobileNode, Foreign Agent and Home Agent of the Mobile IP Protocol.

RFC 2007 Catalogue of Network Training Materials

Authors: J. Foster, M. Isaacs, M. Prior.

Date: October 1996

Formats: txt html json

Also: FYI 0029

Status: INFORMATIONAL

DOI: 10.17487/RFC 2007

The purpose of this document is to provide a catalogue of qualityNetwork Training Materials for use by Internet trainers in training their users. By providing such a collection of pointers to useful resources, it is hoped that trainers will be relieved of much of the load of producing current training materials.

RFC 2008 Implications of Various Address Allocation Policies for Internet Routing

Authors: Y. Rekhter, T. Li.

Date: October 1996

Formats: txt json html

Also: BCP 0007

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2008

The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC 2009 GPS-Based Addressing and Routing

Authors: T. Imielinski, J. Navas.

Date: November 1996

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2009

This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community.

RFC 2010 Operational Criteria for Root Name Servers

Authors: B. Manning, P. Vixie.

Date: October 1996

Formats: txt json html

Obsoleted by: RFC 2870

Status: INFORMATIONAL

DOI: 10.17487/RFC 2010

This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment.

RFC 2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2

Authors: K. McCloghrie, Ed..

Date: November 1996

Formats: txt json html

Obsoleted by: RFC 4293

Updates: RFC 1213

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2011

This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK]

RFC 2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2

Authors: K. McCloghrie, Ed..

Date: November 1996

Formats: txt html json

Obsoleted by: RFC 4022

Updates: RFC 1213

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2012

This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK]

RFC 2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2

Authors: K. McCloghrie, Ed..

Date: November 1996

Formats: txt html json

Obsoleted by: RFC 4113

Updates: RFC 1213

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2013

This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK]

RFC 2014 IRTF Research Group Guidelines and Procedures

Authors: A. Weinrib, J. Postel.

Date: October 1996

Formats: txt json html

Also: BCP 0008

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2014

The Internet Research Task Force (IRTF) has responsibility for organizing groups to investigate research topics related to theInternet protocols, applications, and technology. IRTF activities are organized into Research Groups. This document describes the guidelines and procedures for formation and operation of IRTFResearch Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group(IRSG) and the Internet Architecture Board (IAB). The basic duties of IRTF participants, including the IRTF Chair, Research Group Chairs and IRSG members are defined.

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 2016 Uniform Resource Agents (URAs)

Authors: L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan.

Date: October 1996

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2016

This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. Not a generalized architecture for active objects that roam the Internet, these agents are modeled as extensions of existing pieces of the Internet information infrastructure. This experimental agent technology focuses on the necessary information structures to encapsulate Internet activities into objects that can be activated, transformed, and combined into larger structured activities.

RFC 2017 Definition of the URL MIME External-Body Access-Type

Authors: N. Freed, K. Moore, A. Cargille.

Date: October 1996

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2017

This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK]

RFC 2018 TCP Selective Acknowledgment Options

Authors: M. Mathis, J. Mahdavi, S. Floyd, A. Romanow.

Date: October 1996

Formats: txt json html

Obsoletes: RFC 1072

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2018

TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received.
A Selective Acknowledgment (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments.
This memo proposes an implementation of SACK and discusses its performance and related issues.

RFC 2019 Transmission of IPv6 Packets Over FDDI

Authors: M. Crawford.

Date: October 1996

Formats: txt json html

Obsoleted by: RFC 2467

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2019

This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK]

RFC 2020 IEEE 802.12 Interface MIB

Authors: J. Flick.

Date: October 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2020

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 network interfaces based on IEEE 802.12. [STANDARDS-TRACK]

RFC 2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2

Authors: S. Waldbusser.

Date: January 1997

Formats: txt json html

Obsoleted by: RFC 4502

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2021

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring devices.

RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks

Authors: G. Armitage.

Date: November 1996

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2022

Mapping the connectionless IP multicast service over the connection oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task.This memo describes a mechanism to support the multicast needs ofLayer 3 protocols in general, and describes its application to IP multicasting in particular.
ATM based IP hosts and routers use a Multicast Address ResolutionServer (MARS) to support RFC 1112 style Level 2 IP multicast over theATM Forum's UNI 3.0/3.1 point to multipoint connection service.Clusters of endpoints share a MARS and use it to track and disseminate information identifying the nodes listed as receivers for given multicast groups. This allows endpoints to establish and manage point to multipoint VCs when transmitting to the group.
The MARS behaviour allows Layer 3 multicasting to be supported using either meshes of VCs or ATM level multicast servers. This choice may be made on a per-group basis, and is transparent to the endpoints.

RFC 2023 IP Version 6 over PPP

Authors: D. Haskin, E. Allen.

Date: October 1996

Formats: txt html json

Obsoleted by: RFC 2472

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2023

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links.

RFC 2024 Definitions of Managed Objects for Data Link Switching using SMIv2

Authors: D. Chen, Ed., P. Gayek, S. Nix.

Date: October 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2024

This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw) [1].
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI [2], and semantically identical to the SNMPv1 definitions [3].

RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM)

Authors: C. Adams.

Date: October 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2025

This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security ServiceApplication Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism.

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 2027 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees

Authors: J. Galvin.

Date: October 1996

Formats: txt html json

Obsoleted by: RFC 2282

Status: INFORMATIONAL

DOI: 10.17487/RFC 2027

The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self- consistent, organized compilation of the process as it is known today.

RFC 2028 The Organizations Involved in the IETF Standards Process

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 2029 RTP Payload Format of Sun's CellB Video Encoding

Authors: M. Speer, D. Hoffman.

Date: October 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2029

This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB.

RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI

Authors: D. Mills.

Date: October 1996

Formats: txt json html

Obsoletes: RFC 1769

Obsoleted by: RFC 4330

Status: INFORMATIONAL

DOI: 10.17487/RFC 2030

This memorandum describes the Simple Network Time Protocol (SNTP)Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. When operating with current and previous NTP and SNTP versions, SNTP Version 4 involves no changes to the NTP specification or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
The only significant protocol change in SNTP Version 4 over previous versions of NTP and SNTP is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI[COL94] addressing. However, SNTP Version 4 includes certain optional extensions to the basic Version 3 model, including an anycast mode and an authentication scheme designed specifically for multicast and anycast modes. While the anycast mode extension is described in this document, the authentication scheme extension will be described in another document to be published later. Until such time that a definitive specification is published, these extensions should be considered provisional.
This memorandum obsoletes RFC-1769, which describes SNTP Version 3.Its purpose is to correct certain inconsistencies in the previous document and to clarify header formats and protocol operations for current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 andOSI), which are also used for SNTP. A working knowledge of the NTPVersion 3 specification RFC-1305 is not required for an implementation of SNTP.

RFC 2031 IETF-ISOC relationship

Authors: E. Huizer.

Date: October 1996

Formats: txt json html

Obsoleted by: RFC 8712

Status: INFORMATIONAL

DOI: 10.17487/RFC 2031

This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary.

RFC 2032 RTP Payload Format for H.261 Video Streams

Authors: T. Turletti, C. Huitema.

Date: October 1996

Formats: txt html json

Obsoleted by: RFC 4587

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2032

This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK]

RFC 2033 Local Mail Transfer Protocol

Authors: J. Myers.

Date: October 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2033

SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes

Authors: N. Freed.

Date: October 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2034

This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK]

RFC 2035 RTP Payload Format for JPEG-compressed Video

Authors: L. Berc, W. Fenner, R. Frederick, S. McCanne.

Date: October 1996

Formats: txt json html

Obsoleted by: RFC 2435

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2035

This memo describes the RTP payload format for JPEG video streams.The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame.
This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem- conf@es.net and/or the author(s).

RFC 2036 Observations on the use of Components of the Class A Address Space within the Internet

Authors: G. Huston.

Date: October 1996

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 2036

This document is a commentary on the recommendation that IANA commence allocation of the presently unallocated components of theClass A address space to registries, for deployment within theInternet as class-less address blocks.
The document examines the implications for service providers and end clients within this environment. The document notes the major conclusion that widespread adoption of class-less routing protocols is required, within a relatively rapid timeframe for this recommendation to be effective.

RFC 2037 Entity MIB using SMIv2

Authors: K. McCloghrie, A. Bierman.

Date: October 1996

Formats: txt html json

Obsoleted by: RFC 2737

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2037

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]

RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video

Authors: D. Hoffman, G. Fernando, V. Goyal.

Date: October 1996

Formats: txt json html

Obsoleted by: RFC 2250

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2038

This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF.

RFC 2039 Applicability of Standards Track MIBs to Management of World Wide Web Servers

Authors: C. Kalbfleisch.

Date: November 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2039

This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms

Authors: R. Baldwin, R. Rivest.

Date: October 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2040

This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 2041 Mobile Network Tracing

Authors: B. Noble, G. Nguyen, M. Satyanarayanan, R. Katz.

Date: October 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2041

Mobile networks are both poorly understood and difficult to experiment with. This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. The RFC is a status report on our work tracing mobile networks. Our goal is to begin discussion on a standard format for mobile network tracing as well as a testbed for mobile systems research. We present our format for collecting mobile network traces, and tools to produce from such traces analytical models of mobile network behavior.
We also describe a set of tools to provide network modulation based on collected traces. Modulation allows the emulation of wireless channel latency, bandwidth, loss, and error rates on private, wired networks. This allows system designers to test systems in a realistic yet repeatable manner.

RFC 2042 Registering New BGP Attribute Types

Authors: B. Manning.

Date: January 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2042

This document describes the process for creating new BGP attribute type codes. Basic attribute type codes are described in RFC 1771, pages 12 through 15. These, and new attribute type codes that are used in the Internet are registered with the IANA. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 2043 The PPP SNA Control Protocol (SNACP)

Authors: A. Fuqua.

Date: October 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2043

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, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP.

RFC 2044 UTF-8, a transformation format of Unicode and ISO 10646

Authors: F. Yergeau.

Date: October 1996

Formats: txt html json

Obsoleted by: RFC 2279

Status: INFORMATIONAL

DOI: 10.17487/RFC 2044

The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. 16-bit characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range: US-ASCII characters are encoded in one octet having the usual US-ASCII value, and any octet with such a value can only be an US-ASCII character.This provides compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.

RFC 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 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples

Authors: N. Freed, N. Borenstein.

Date: November 1996

Formats: txt html json

Obsoletes: RFC 1521, RFC 1522, RFC 1590

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2049

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.
The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. The 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. This fifth and final document 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. Appendix B of this document describes differences and changes from previous versions.

RFC 2050 Internet Registry IP Allocation Guidelines

Authors: K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel.

Date: November 1996

Formats: txt html json

Obsoletes: RFC 1466

Obsoleted by: RFC 7020

Status: HISTORIC

DOI: 10.17487/RFC 2050

This document describes the registry system for the distribution of globally unique Internet address space and registry operations.Particularly this document describes the rules and guidelines governing the distribution of this address space.
This document describes the IP assignment policies currently used by the Regional Registries to implement the guidelines developed by theIANA. The guidelines and these policies are subject to revision at the direction of the IANA. The registry working group (IRE WG) will be discussing these issues and may provide advice to the IANA about possible revisions.
This document replaces RFC 1466, with all the guidelines and procedures updated and modified in the light of experience.
This document does not describe private Internet address space and multicast address space. It also does not describe regional and local refinements of the global rules and guidelines.
This document can be considered the base set of operational guidelines in use by all registries. Additional guidelines may be imposed by a particular registry as appropriate.

RFC 2051 Definitions of Managed Objects for APPC using SMIv2

Authors: M. Allen, B. Clouston, Z. Kielczewski, W. Kwan, B. Moore.

Date: October 1996

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2051

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK]

RFC 2052 A DNS RR for specifying the location of services (DNS SRV)

Authors: A. Gulbrandsen, P. Vixie.

Date: October 1996

Formats: txt json html

Obsoleted by: RFC 2782

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2052

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX).

RFC 2053 The AM (Armenia) Domain

Authors: E. Der-Danieliantz.

Date: October 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2053

The AM Domain is an official Internet top-level domain of Armenia. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 2054 WebNFS Client Specification

Authors: B. Callaghan.

Date: October 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2054

This document describes a lightweight binding mechanism that allowsNFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. In removing this overhead, WebNFS clients see benefits in faster response to requests, easy transit of packet filter firewalls and TCP-based proxies, and better server scalability.

RFC 2055 WebNFS Server Specification

Authors: B. Callaghan.

Date: October 1996

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2055

This document describes the specifications for a server of WebNFS clients. WebNFS extends the semantics of versions 2 and 3 of the NFS protocols to allow clients to obtain filehandles more easily, without recourse to the portmap or MOUNT protocols. In removing the need for these protocols, WebNFS clients see benefits in faster response to requests, easy transit of firewalls and better server scalabilityThis description is provided to facilitate compatible implementations of WebNFS servers.

RFC 2056 Uniform Resource Locators for Z39.50

Authors: R. Denenberg, J. Kunze, D. Lynch.

Date: November 1996

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2056

Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK]

RFC 2057 Source Directed Access Control on the Internet

Authors: S. Bradner.

Date: November 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2057

This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 2058 Remote Authentication Dial In User Service (RADIUS)

Authors: C. Rigney, A. Rubens, W. Simpson, S. Willens.

Date: January 1997

Formats: txt html json

Obsoleted by: RFC 2138

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2058

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server.

RFC 2059 RADIUS Accounting

Authors: C. Rigney.

Date: January 1997

Formats: txt html json

Obsoleted by: RFC 2139

Status: INFORMATIONAL

DOI: 10.17487/RFC 2059

This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer.

RFC 2060 Internet Message Access Protocol - Version 4rev1

Authors: M. Crispin.

Date: December 1996

Formats: txt html json

Obsoletes: RFC 1730

Obsoleted by: RFC 3501

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2060

The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]).
IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.
IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in [ACAP].
IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP].
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. In the course of the evolution ofIMAP4rev1, some aspects in the earlier protocol have become obsolete.Obsolete commands, responses, and data formats which an IMAP4rev1 implementation may encounter when used with an earlier implementation are described in [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct) variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest.

RFC 2061 IMAP4 Compatibility with IMAP2bis

Authors: M. Crispin.

Date: December 1996

Formats: txt html json

Obsoletes: RFC 1730

Status: INFORMATIONAL

DOI: 10.17487/RFC 2061

This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 2062 Internet Message Access Protocol - Obsolete Syntax

Authors: M. Crispin.

Date: December 1996

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2062

This document describes obsolete syntax which may be encountered byIMAP4 implementations which deal with older versions of the InternetMail Access Protocol. IMAP4 implementations MAY implement this syntax in order to maximize interoperability with older implementations.
This document repeats information from earlier documents, most notably RFC 1176 and RFC 1730.

RFC 2063 Traffic Flow Measurement: Architecture

Authors: N. Brownlee, C. Mills, G. Ruth.

Date: January 1997

Formats: txt json html

Obsoleted by: RFC 2722

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2063

This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. It is intended to provide a starting point for the Realtime Traffic Flow Measurement Working Group.

RFC 2064 Traffic Flow Measurement: Meter MIB

Authors: N. Brownlee.

Date: January 1997

Formats: txt html json

Obsoleted by: RFC 2720

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2064

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters.

RFC 2065 Domain Name System Security Extensions

Authors: D. Eastlake 3rd, C. Kaufman.

Date: January 1997

Formats: txt html json

Obsoleted by: RFC 2535

Updates: RFC 1034, RFC 1035

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2065

The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases.
The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.
In addition, the security extensions provide for the optional authentication of DNS protocol transactions.

RFC 2066 TELNET CHARSET Option

Authors: R. Gellens.

Date: January 1997

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2066

This document specifies a mechanism for passing character set and translation information between a TELNET client and server. Use of this mechanism enables an application used by a TELNET user to send and receive data in the correct character set.
Either side can (subject to option negotiation) at any time request that a (new) character set be used.

RFC 2067 IP over HIPPI

Authors: J. Renwick.

Date: January 1997

Formats: txt json html

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2067

ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation ofIEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. ANSI X3.222-1993 (HIPPI-SC[4]) describes the operation of HIPPI physical switches. The ANSI committee responsible for these standards chose to leave HIPPI networking issues largely outside the scope of their standards; this document describes the use of HIPPI switches as IP local area networks.
This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is intended to replace it in the Standards Track. RFC 1374 has been aProposed Standard since November, 1992, with at least 10 implementations of IP encapsulation and HIPPI switch discipline. No major changes to it are required. However, the ARP part of RFC 1374 has not had sufficient implementation experience to be advanced toDraft Standard. The present document contains all of RFC 1374 except for the description ARP, which has been moved into a separate document.

RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1

Authors: R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee.

Date: January 1997

Formats: txt html json

Obsoleted by: RFC 2616

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2068

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods.A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".

RFC 2069 An Extension to HTTP : Digest Access Authentication

Authors: J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart.

Date: January 1997

Formats: txt html json

Obsoleted by: RFC 2617

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2069

The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". Like Basic,Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.

RFC 2070 Internationalization of the Hypertext Markup Language

Authors: F. Yergeau, G. Nicol, G. Adams, M. Duerst.

Date: January 1997

Formats: txt html json

Obsoleted by: RFC 2854

Status: HISTORIC

DOI: 10.17487/RFC 2070

The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. Initially, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded character set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other languages, using other coded character sets or character encodings, at the expense of interoperability.
This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use with all languages of the world.

RFC 2071 Network Renumbering Overview: Why would I want it and what is it anyway?

Authors: P. Ferguson, H. Berkowitz.

Date: January 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2071

The PIER [Procedures for Internet/Enterprise Renumbering] working group is compiling a series of documents to assist and instruct organizations in their efforts to renumber. However, it is becoming apparent that, with the increasing number of new Internet ServiceProviders (ISP's) and organizations getting connected to the Internet for the first time, the concept of network renumbering needs to be further defined. This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so.

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 2073 An IPv6 Provider-Based Unicast Address Format

Authors: Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel.

Date: January 1997

Formats: txt json html

Obsoleted by: RFC 2374

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2073

This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]

RFC 2074 Remote Network Monitoring MIB Protocol Identifiers

Authors: A. Bierman, R. Iddon.

Date: January 1997

Formats: txt html json

Obsoleted by: RFC 2895

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2074

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK]

RFC 2075 IP Echo Host Service

Authors: C. Partridge.

Date: January 1997

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2075

This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. The effect is that datagrams sent to the echo host are sent back to the source, as if they originated at the echo host.

RFC 2076 Common Internet Message Headers

Authors: J. Palme.

Date: February 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2076

This memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521,RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For each header, the memo gives a short description and a reference to the RFC in which the header is defined.

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 2078 Generic Security Service Application Program Interface, Version 2

Authors: J. Linn.

Date: January 1997

Formats: txt html json

Obsoletes: RFC 1508

Obsoleted by: RFC 2743

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2078

The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification definesGSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms
This memo revises RFC-1508, making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.

RFC 2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)

Authors: M. Smith.

Date: January 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2079

Uniform Resource Locators (URLs) are being widely used to specify the location of Internet resources. There is an urgent need to be able to include URLs in directories that conform to the LDAP and X.500 information models, and a desire to include other types of UniformResource Identifiers (URIs) as they are defined. A number of independent groups are already experimenting with the inclusion ofURLs in LDAP and X.500 directories. This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way.

RFC 2080 RIPng for IPv6

Authors: G. Malkin, R. Minnear.

Date: January 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2080

This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in theIPv4 Internet.
This specification represents the minimum change to the RoutingInformation Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723[2], necessary for operation over IPv6 [3].

RFC 2081 RIPng Protocol Applicability Statement

Authors: G. Malkin.

Date: January 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2081

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet.This report is a prerequisite to advancing RIPng on the standards track.

RFC 2082 RIP-2 MD5 Authentication

Authors: F. Baker, R. Atkinson.

Date: January 1997

Formats: txt json html

Obsoleted by: RFC 4822

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2082

Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK]

RFC 2083 PNG (Portable Network Graphics) Specification Version 1.0

Authors: T. Boutell.

Date: March 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2083

This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. PNG provides a patent-free replacement forGIF and can also replace many common uses of TIFF. Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits.
PNG is designed to work well in online viewing applications, such as the World Wide Web, so it is fully streamable with a progressive display option. PNG is robust, providing both full file integrity checking and simple detection of common transmission errors. Also,PNG can store gamma and chromaticity data for improved color matching on heterogeneous platforms.
This specification defines the Internet Media Type image/png.

RFC 2084 Considerations for Web Transaction Security

Authors: G. Bossert, S. Cooper, W. Drummond.

Date: January 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2084

This document specifies the requirements for the provision of security services to the HyperText Transport Protocol. These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services. Such services may be provided as extensions to HTTP, or as an encapsulating security protocol. Secondary requirements include ease of integration and support of multiple mechanisms for providing these services.

RFC 2085 HMAC-MD5 IP Authentication with Replay Prevention

Authors: M. Oehler, R. Glenn.

Date: February 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2085

This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks.

RFC 2086 IMAP4 ACL extension

Authors: J. Myers.

Date: January 1997

Formats: txt json html

Obsoleted by: RFC 4314

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2086

The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]

RFC 2087 IMAP4 QUOTA extension

Authors: J. Myers.

Date: January 1997

Formats: txt json html

Obsoleted by: RFC 9208

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2087

The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK]

RFC 2088 IMAP4 non-synchronizing literals

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 2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent

Authors: B. Wijnen, D. Levi.

Date: January 1997

Formats: txt html json

Obsoleted by: RFC 2576

Status: INFORMATIONAL

DOI: 10.17487/RFC 2089

The goal of this memo is to document a common way of mapping anSNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2).

RFC 2090 TFTP Multicast Option

Authors: A. Emberson.

Date: February 1997

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2090

The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.
This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. The TFTP Option Extension mechanism is described in [2].
Often when similar computers are booting remotely they will each download the same image file. By adding multicast into the TFTP option set, two or more computers can download a file concurrently, thus increasing network efficiency.
This document assumes that the reader is familiar with the terminology and notation of both [1] and [2].

RFC 2091 Triggered Extensions to RIP to Support Demand Circuits

Authors: G. Meyer, S. Sherry.

Date: January 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2091

This document defines a modification which can be applied toBellman-Ford (distance vector) algorithm information broadcasting protocols - for example IP RIP, Netware RIP or Netware SAP - which makes it feasible to run them on connection oriented Public DataNetworks.
This proposal has a number of efficiency advantages over the DemandRIP proposal (RFC 1582).

RFC 2092 Protocol Analysis for Triggered RIP

Authors: S. Sherry, G. Meyer.

Date: January 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2092

As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support DemandCircuits [2] and the current implementation experience.
As a result of the improved characteristics of Triggered RIP, it is proposed that Demand RIP [5] be obsoleted.

RFC 2093 Group Key Management Protocol (GKMP) Specification

Authors: H. Harney, C. Muckenhirn.

Date: July 1997

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2093

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocol has the following advantages: 1) virtually invisible to operator, 2) no central key distribution site is needed, 3) only group members have the key, 4) sender or receiver oriented operation, 5) can make use of multicast communications protocols.

RFC 2094 Group Key Management Protocol (GKMP) Architecture

Authors: H. Harney, C. Muckenhirn.

Date: July 1997

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2094

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocol has the following advantages: 1) virtually invisible to operator, 2) no central key distribution site is needed, 3) only group members have the key, 4) sender or receiver oriented operation, 5) can make use of multicast communications protocols.

RFC 2095 IMAP/POP AUTHorize Extension for Simple Challenge/Response

Authors: J. Klensin, R. Catoe, P. Krumviede.

Date: January 1997

Formats: txt html json

Obsoleted by: RFC 2195

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2095

While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access.This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734.

RFC 2096 IP Forwarding Table MIB

Authors: F. Baker.

Date: January 1997

Formats: txt json html

Obsoletes: RFC 1354

Obsoleted by: RFC 4292

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2096

This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK]

RFC 2097 The PPP NetBIOS Frames Control Protocol (NBFCP)

Authors: G. Pall.

Date: January 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2097

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, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
The NBF protocol [3] was originally called the NetBEUI protocol. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP.
The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. It is not applicable for connecting two LANs together due to NetBIOS name limitations and NetBIOS name defense mechanisms.

RFC 2098 Toshiba's Router Architecture Extensions for ATM : Overview

Authors: Y. Katsube, K. Nagami, H. Esaki.

Date: February 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2098

This memo describes a new internetworking architecture which makes better use of the property of ATM. IP datagrams are transferred along hop-by-hop path via routers, but datagram assembly/disassembly and IP header processing are not necessarily carried out at individual routers in the proposed architecture. A concept of "CellSwitch Router (CSR)" is introduced as a new internetworking equipment, which has ATM cell switching capabilities in addition to conventional IP datagram forwarding. Proposed architecture can provide applications with high-throughput and low-latency ATM pipes while retaining current router-based internetworking concept. It also provides applications with specific QoS/bandwidth by cooperating with internetworking level resource reservation protocols such asRSVP.

RFC 2099 Request for Comments Summary RFC Numbers 2000-2099

Authors: J. Elliott.

Date: March 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2099

RFC 2100 The Naming of Hosts

Authors: J. Ashworth.

Date: 1 April 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2100

This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 2101 IPv4 Address Behaviour Today

Authors: B. Carpenter, J. Crowcroft, Y. Rekhter.

Date: February 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2101

The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. A short section on IPv6 addresses mentions the main points of similarity with, and difference from, IPv4.

RFC 2102 Multicast Support for Nimrod : Requirements and Solution Approaches

Authors: R. Ramanathan.

Date: February 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2102

Nimrod does not specify a particular solution for multicasting.Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. We compare existing approaches for multicasting within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support multicast in Nimrod using the scheme currently being developed within the IETF - namely, the Protocol Indpendent Multicast(PIM) protocol.

RFC 2103 Mobility Support for Nimrod : Challenges and Solution Approaches

Authors: R. Ramanathan.

Date: February 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2103

We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support.We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support mobility in Nimrod using the scheme currently being developed within the IETF - namely, the Mobile-IP protocol.

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 2105 Cisco Systems' Tag Switching Architecture Overview

Authors: Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow.

Date: February 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2105

This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. Forwarding is accomplished using simple label-swapping techniques, while the existing network layer routing protocols plus mechanisms for binding and distributing tags are used for control. Tag switching can retain the scaling properties of IP, and can help improve the scalability of IP networks. While tag switching does not rely on ATM, it can straightforwardly be applied to ATM switches. A range of tag switching applications and deployment scenarios are described.

RFC 2106 Data Link Switching Remote Access Protocol

Authors: S. Chiang, J. Lee, H. Yasuda.

Date: February 1997

Formats: txt json html

Obsoleted by: RFC 2114

Status: INFORMATIONAL

DOI: 10.17487/RFC 2106

This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to drap@cisco.com.

RFC 2107 Ascend Tunnel Management Protocol - ATMP

Authors: K. Hamzeh.

Date: February 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2107

This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. The user's client software uses an address contained in the home network address space for the remote access. Packets to and from the home network are tunneled by the Network Access Server (NAS) to which the user connects and a Home Agent (HA) on the user's home network. This allows for the support of access to Virtual Private Networks and also allows for the use of protocols other than IP to be carried over the tunnel. An example of how the RADIUS (Remote Authentication Dial InUser Service) can be used to provide the necessary configuration information to support this service is also provided.

RFC 2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2

Authors: K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie.

Date: February 1997

Formats: txt html json

Obsoletes: RFC 1516

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2108

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing IEEE 802.3 10 and 100Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10& 100 Mb/s Management," October 26, 1995.

RFC 2109 HTTP State Management Mechanism

Authors: D. Kristol, L. Montulli.

Date: February 1997

Formats: txt html json

Obsoleted by: RFC 2965

Status: HISTORIC

DOI: 10.17487/RFC 2109

This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK]

RFC 2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)

Authors: J. Palme, A. Hopmann.

Date: March 1997

Formats: txt html json

Obsoleted by: RFC 2557

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2110

Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate usingHTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type multipart/related and specifies the MIME content-headers "Content-Location" and "Content-Base".

RFC 2111 Content-ID and Message-ID Uniform Resource Locators

Authors: E. Levinson.

Date: March 1997

Formats: txt html json

Obsoleted by: RFC 2392

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2111

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message.

RFC 2112 The MIME Multipart/Related Content-type

Authors: E. Levinson.

Date: March 1997

Formats: txt json html

Obsoletes: RFC 1872

Obsoleted by: RFC 2387

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2112

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use.

RFC 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 2114 Data Link Switching Client Access Protocol

Authors: S. Chiang, J. Lee, H. Yasuda.

Date: February 1997

Formats: txt html json

Obsoletes: RFC 2106

Status: INFORMATIONAL

DOI: 10.17487/RFC 2114

This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to dcap@cisco.com.

RFC 2115 Management Information Base for Frame Relay DTEs Using SMIv2

Authors: C. Brown, F. Baker.

Date: September 1997

Formats: txt html json

Obsoletes: RFC 1315

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2115

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for managing Frame Relay interfaces on DTEs. [STANDARDS-TRACK]

RFC 2116 X.500 Implementations Catalog-96

Authors: C. Apple, K. Rossen.

Date: April 1997

Formats: txt json html

Obsoletes: RFC 1632

Also: FYI 0011

Status: INFORMATIONAL

DOI: 10.17487/RFC 2116

This document is a revision to [RFC 1632]: A Revised Catalog ofAvailable X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations ofX.500, including commercial products and openly available offerings.[RFC 1632] is a revision of [RFC 1292]. We contacted each contributor to [RFC 1632] to request an update and published the URL of the WWW home page survey template in several mailing lists to encourage the submission of new product descriptions.
This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces.

RFC 2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification

Authors: D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei.

Date: June 1997

Formats: txt json html

Obsoleted by: RFC 2362

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2117

This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community.

RFC 2118 Microsoft Point-To-Point Compression (MPPC) Protocol

Authors: G. Pall.

Date: March 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2118

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Microsoft Point to PointCompression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets.

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 2120 Managing the X.500 Root Naming Context

Authors: D. Chadwick.

Date: March 1997

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2120

The X.500 Standard [X.500 93] has the concept of first level DSAs, whose administrators must collectively manage the root naming context through bi-lateral agreements or other private means which are outside the scope of the X.500 Standard.
The NameFLOW-Paradise X.500 service has an established procedure for managing the root naming context, which currently uses Quipu proprietary replication mechanisms and a root DSA. The benefits that derive from this are twofold:
- firstly it is much easier to co-ordinate the management of the root context information, when there is a central point of administration,
- secondly the performance of one-level Search operations is greatly improved because the Quipu distribution and replication mechanism does not have a restriction that exists in the 1988 and1993 X.500 Standard.
The NameFLOW-Paradise project is moving towards 1993 ISO X.500Standard replication protocols and wants to standardise the protocol and procedure for managing the root naming context which will be based on 1993 X.500 Standard protocols. Such a protocol and procedure will be useful to private X.500 domains as well as to the InternetX.500 public domain. It is imperative that overall system performance is not degraded by this transition.
This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard.

RFC 2121 Issues affecting MARS Cluster Size

Authors: G. Armitage.

Date: March 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2121

IP multicast over ATM currently uses the MARS model [1] to manage the use of ATM pt-mpt SVCs for IP multicast packet forwarding. The scope of any given MARS services is the MARS Cluster - typically the same as an IPv4 Logical IP Subnet (LIS). Current IP/ATM networks are usually architected with unicast routing and forwarding issues dictating the sizes of individual LISes. However, as IP multicast is deployed as a service, the size of a LIS will only be as big as aMARS Cluster can be. This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups.

RFC 2122 VEMMI URL Specification

Authors: D. Mavrakis, H. Layec, K. Kartmann.

Date: March 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2122

A new URL scheme, "vemmi" is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK]

RFC 2123 Traffic Flow Measurement: Experiences with NeTraMet

Authors: N. Brownlee.

Date: March 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2123

This memo records experiences in implementing and using the TrafficFlow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet.

RFC 2124 Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0

Authors: P. Amsden, J. Amweg, P. Calato, S. Bensley, G. Lyons.

Date: March 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2124

Light-weight Flow Admission Protocol, LFAP, allows an external FlowAdmission Service (FAS) to manage flow admission at the switch, allowing flexible Flow Admission Services to be deployed by a vendor or customer without changes to, or undue burden on, the switch.
Specifically, this document specifies the protocol between the switchConnection Control Entity (CCE) and the external FAS. Using LFAP, aFlow Admission Service can: allow or disallow flows, define the parameters under which a given flow is to operate (operating policy) or, redirect the flow to an alternate destination. The FAS may also maintain details of current or historical flows for billing, capacity planning and other purposes.

RFC 2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP)

Authors: C. Richards, K. Smith.

Date: March 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2125

This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol[2]. This is done by defining the Bandwidth Allocation Protocol(BAP), as well as its associated control protocol, the BandwidthAllocation Control Protocol (BACP). BAP can be used to manage the number of links in a multilink bundle. BAP defines datagrams to co- ordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection.

RFC 2126 ISO Transport Service on top of TCP (ITOT)

Authors: Y. Pouffary, A. Young.

Date: March 1997

Formats: txt json html

Updates: RFC 1006

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2126

This document is a revision to STD35, RFC1006 written by Marshall T.Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987, much experience has been gained in using ISO transport services on top of TCP. This document refines the protocol and will eventually supersede RFC1006.
This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006.
The goal of this version is to minimise the number of changes toRFC1006 and ISO 8073 transport protocol definitions, while maximising performance, extending its applicability and protecting the installed base of RFC1006 users.

RFC 2127 ISDN Management Information Base using SMIv2

Authors: G. Roeck, Ed..

Date: March 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2127

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 minimal set of managed objects for SNMP- based management of ISDN terminal interfaces. ISDN interfaces are supported on a variety of equipment (for data and voice) including terminal adapters, bridges, hosts, and routers.
This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This document is a product of the ISDN MIB working group within theInternet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author.
The current version of this document reflects changes made during the last call period and the IESG review.

RFC 2128 Dial Control Management Information Base using SMIv2

Authors: G. Roeck, Ed..

Date: March 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2128

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 demand access circuits, including ISDN.
This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This document is a product of the ISDN MIB working group within theInternet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author.

RFC 2129 Toshiba's Flow Attribute Notification Protocol (FANP) Specification

Authors: K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki.

Date: April 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2129

This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. In cut-through packet forwarding, a router doesn't have to perform conventional IP packet processing for received packets. FANP indicates mapping information between a datalink connection and a packet flow to the neighbor node and helps a pair of nodes manage the mapping information. By usingFANP, routers (e.g., CSR; Cell Switch Router) can forward incoming packets based on their datalink-level connection identifiers, bypassing usual IP packet processing. The design policy of the FANP is;
(1) soft-state cut-through path (Dedicated-VC) management(2) protocol between neighbor nodes instead of end-to-end(3) applicable to any connection oriented datalink platform

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 2133 Basic Socket Interface Extensions for IPv6

Authors: R. Gilligan, S. Thomson, J. Bound, W. Stevens.

Date: April 1997

Formats: txt json html

Obsoleted by: RFC 2553

Status: INFORMATIONAL

DOI: 10.17487/RFC 2133

The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [5].

RFC 2134 Articles of Incorporation of Internet Society

Authors: ISOC Board of Trustees.

Date: April 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2134

These are the articles of incorporation of the Internet Society.They are published for the information of the IETF community at the request of the poisson working group.

RFC 2135 Internet Society By-Laws

Authors: ISOC Board of Trustees.

Date: April 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2135

These are the by-laws of the Internet Society, as amended, as of June1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws.

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 2137 Secure Domain Name System Dynamic Update

Authors: D. Eastlake 3rd.

Date: April 1997

Formats: txt json html

Obsoleted by: RFC 3007

Updates: RFC 1035

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2137

Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services[RFC2065]. DNS Dynamic Update operations have also been defined[RFC2136], but without a detailed description of security for the update operation. This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys.

RFC 2138 Remote Authentication Dial In User Service (RADIUS)

Authors: C. Rigney, A. Rubens, W. Simpson, S. Willens.

Date: April 1997

Formats: txt html json

Obsoletes: RFC 2058

Obsoleted by: RFC 2865

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2138

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server.

RFC 2139 RADIUS Accounting

Authors: C. Rigney.

Date: April 1997

Formats: txt html json

Obsoletes: RFC 2059

Obsoleted by: RFC 2866

Status: INFORMATIONAL

DOI: 10.17487/RFC 2139

This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer.

RFC 2140 TCP Control Block Interdependence

Authors: J. Touch.

Date: April 1997

Formats: txt json html

Obsoleted by: RFC 9040

Status: INFORMATIONAL

DOI: 10.17487/RFC 2140

This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round- trip time estimates, congestion control information, and process information. This state is currently maintained on a per-connection basis in the TCP control block, but should be shared across connections to the same host. The goal is to improve transient transport performance, while maintaining backward-compatibility with existing implementations.
This document is a product of the LSAM project at ISI.

RFC 2141 URN Syntax

Authors: R. Moats.

Date: May 1997

Formats: txt json html

Obsoleted by: RFC 8141

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2141

Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it.

RFC 2142 Mailbox Names for Common Services, Roles and Functions

Authors: D. Crocker.

Date: May 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2142

This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]

RFC 2143 Encapsulating IP with the Small Computer System Interface

Authors: B. Elliston.

Date: May 1997

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2143

This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 2144 The CAST-128 Encryption Algorithm

Authors: C. Adams.

Date: May 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2144

There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.
This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm (Section 2), the s-boxes (AppendixA), and a set of test vectors (Appendix B).

RFC 2145 Use and Interpretation of HTTP Version Numbers

Authors: J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk.

Date: May 1997

Formats: txt json html

Obsoleted by: RFC 7230

Status: INFORMATIONAL

DOI: 10.17487/RFC 2145

HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existingHTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP.

RFC 2146 U.S

Authors: Government Internet Domain Names. Federal Networking Council.

Date: May 1997

Formats: txt html json

Obsoletes: RFC 1816

Status: INFORMATIONAL

DOI: 10.17487/RFC 2146

This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. Two documents are recognized as constituting documentation on the US government structure: FIPS 95-1 provides a standard recognized structure into which domain registrations for .GOV and FED.US can fit; and, the US Government Manual [3], a special publication of theFederal Register, provides official documentation of the government structure. The latter document may be subject to more timely updates than the former. Either document is suitable for determining which entities qualify for second-level domain registration within .GOV andFED.US.
As a side effect, this RFC reduces the number of .GOV and FED.US level registrations and reduces the workload on the registration authority. Previous versions of this document did not address theFED.US domain. This document anticipates the migration of the .GOV domain into the FED.US domain, in keeping with common practice on theInternet today.

RFC 2147 TCP and UDP over IPv6 Jumbograms

Authors: D. Borman.

Date: May 1997

Formats: txt html json

Obsoleted by: RFC 2675

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2147

IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK]

RFC 2148 Deployment of the Internet White Pages Service

Authors: H. Alvestrand, P. Jurg.

Date: September 1997

Formats: txt json html

Also: BCP 0015

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2148

This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC 2149 Multicast Server Architectures for MARS-based ATM multicasting

Authors: R. Talpade, M. Ammar.

Date: May 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2149

A mechanism to support the multicast needs of layer 3 protocols in general, and IP in particular, over UNI 3.0/3.1 based ATM networks has been described in RFC 2022. Two basic approaches exist for the intra-subnet (intra-cluster) multicasting of IP packets. One makes use of a mesh of point to multipoint VCs (the 'VC Mesh' approach), while the other uses a shared point to multipoint tree rooted on aMulticast Server (MCS). This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined inRFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used withRFC 2022 based MARS server and clients, without needing any change in their functionality.

RFC 2150 Humanities and Arts: Sharing Center Stage on the Internet

Authors: J. Max, W. Stickle.

Date: October 1997

Formats: txt json html

Also: FYI 0031

Status: INFORMATIONAL

DOI: 10.17487/RFC 2150

This document is designed primarily for individuals who have limited knowledge of, or experience with, the Internet.
The purpose of this document is to provide members of the Arts andHumanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content.
The intended audience is practicing artists, scholars, related professionals, and others whose knowledge, expertise and support is important to ensuring that the Arts and Humanities are well-placed in the global information infrastructure.

RFC 2151 A Primer On Internet and TCP/IP Tools and Utilities

Authors: G. Kessler, S. Shepard.

Date: June 1997

Formats: txt json html

Obsoletes: RFC 1739

Also: FYI 0030

Status: INFORMATIONAL

DOI: 10.17487/RFC 2151

This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtainInternet and TCP/IP documents, and some resources that help users weave their way through the Internet.

RFC 2152 UTF-7 A Mail-Safe Transformation Format of Unicode

Authors: D. Goldsmith, M. Davis.

Date: May 1997

Formats: txt html json

Obsoletes: RFC 1642

Status: INFORMATIONAL

DOI: 10.17487/RFC 2152

The Unicode Standard, version 2.0, and ISO/IEC 10646-1:1993(E) (as amended) jointly define a character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 2045 through 2049) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641,"Using Unicode with MIME".

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 2154 OSPF with Digital Signatures

Authors: S. Murphy, M. Badger, B. Wellington.

Date: June 1997

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2154

This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co- existence with, standard OSPF V2 is described.

RFC 2155 Definitions of Managed Objects for APPN using SMIv2

Authors: B. Clouston, B. Moore.

Date: June 1997

Formats: txt json html

Obsoleted by: RFC 2455

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2155

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS- TRACK]

RFC 2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME

Authors: S. Kille.

Date: January 1998

Formats: txt html json

Obsoletes: RFC 0987, RFC 1026, RFC 1138, RFC 1148, RFC 1327, RFC 1495

Updates: RFC 0822

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2156

This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK]

RFC 2157 Mapping between X.400 and RFC-822/MIME Message Bodies

Authors: H. Alvestrand.

Date: January 1998

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2157

This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK]

RFC 2158 X.400 Image Body Parts

Authors: H. Alvestrand.

Date: January 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2158

This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK]

RFC 2159 A MIME Body Part for FAX

Authors: H. Alvestrand.

Date: January 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2159

This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK]

RFC 2160 Carrying PostScript in X.400 and MIME

Authors: H. Alvestrand.

Date: January 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2160

This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK]

RFC 2161 A MIME Body Part for ODA

Authors: H. Alvestrand.

Date: January 1998

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2161

This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community.

RFC 2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail

Authors: C. Allocchio.

Date: January 1998

Formats: txt html json

Obsoletes: RFC 1405

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2162

This document describes a set of mappings which will enable inter working between systems operating the ISO/IEC 10021 - CCITT (now ITU)X.400 Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail or VMSmail) protocol.The specifications are valid both within DECnet Phase IV andDECnet/OSI addressing and routing scheme.
The complete scenario of X.400 / MIME / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.
This document covers mainly the X.400 O/R address to/from Mail-11 address mapping and the RFC822 to/from Mail-11 ones; other mappings are based on MIXER specifications. Bodypart mappings are not specified in this document: MIXER and MIME-MHS specifications can be applied to map bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding can be used without modifications within Mail-11 text bodyparts.
This document obsoletes RFC 1405, which was a combined effort ofTERENA Working Group on Messaging, and the IETF X.400 Ops WorkingGroup. This update was prepared by IETF MIXER working group.

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 2164 Use of an X.500/LDAP directory to support MIXER address mapping

Authors: S. Kille.

Date: January 1998

Formats: txt json html

Obsoletes: RFC 1838

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2164

This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK]

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 2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements

Authors: D. Bryant, P. Brittain.

Date: June 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2166

This document specifies
- a set of extensions to RFC 1795 designed to improve the scalability of DLSw- clarifications to RFC 1795 in the light of the implementation experience to-date.
It is assumed that the reader is familiar with DLSw and RFC 1795. No effort has been made to explain these existing protocols or associated terminology.
This document was developed in the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop (AIW). If you would like to participate in future DLSw discussions, please subscribe to the DLSwRIG mailing lists by sending a mail to majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body of the message.

RFC 2167 Referral Whois (RWhois) Protocol V1.5

Authors: S. Williamson, M. Kosters, D. Blacka, J. Singh, K. Zeilstra.

Date: June 1997

Formats: txt html json

Obsoletes: RFC 1714

Status: INFORMATIONAL

DOI: 10.17487/RFC 2167

This memo describes Version 1.5 of the client/server interaction ofRWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This system is primarily hierarchical by design. It allows for the deterministic routing of a query based on hierarchical tags, referring the user closer to the maintainer of the information. While RWhois can be considered a generic directory services protocol, it distinguishes itself from other protocols by providing an integrated, hierarchical architecture and query routing mechanism.

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 2169 A Trivial Convention for using HTTP in URN Resolution

Authors: R. Daniel.

Date: June 1997

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 2169

This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

RFC 2170 Application REQuested IP over ATM (AREQUIPA)

Authors: W. Almesberger, J. Le Boudec, P. Oechslin.

Date: July 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2170

This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This allows the requesting applications to benefit in a straightforward way from ATM's inherent ability to guarantee the quality of service (QoS).
Given a mapping from service classes, as defined by INTSERV[6], toATM traffic descriptors, Arequipa can be used to implement integrated services over ATM link layers. Usage of Arequipa to provide integrated services even if ATM is only available for intermediate links is not discussed in this document but should be straight- forward.
The major advantage of using an approach like Arequipa is that it needs to be implemented only on the hosts using it. It requires no extra service (eg. NHRP or RSVP) to be deployed on the switches or routers of the ATM cloud.
We discuss the implementation of Arequipa for hosts running IPv4 andIPv6. As an illustration, we also discuss how World-Wide-Web applications can use Arequipa to deliver documents with a guaranteed quality of service.
In particular we show how
- Arequipa can be implemented in IPv4 by slightly modifying the- Arequipa can be implemented in IPv6[3] by the appropriate use of flow labels and the extension of the neighbour cache,- Arequipa can be used in the Web by adding extra information in the headers of HTTP requests and responses.
Finally, we address safety and security implications.

RFC 2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1

Authors: K. Murakami, M. Maruyama.

Date: June 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2171

This document describes the protocol MAPOS, Multiple Access Protocol over SONET/SDH, for transmitting network-protocol datagrams overSONET/SDH. It focuses on the core protocol -- other documents listed in the bibliography may be referenced in conjunction with this document to provide support and services for protocols at higher layers.

RFC 2172 MAPOS Version 1 Assigned Numbers

Authors: M. Maruyama, K. Murakami.

Date: June 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2172

This document describes the protocol parameters used in the MultipleAccess Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links.

RFC 2173 A MAPOS version 1 Extension - Node Switch Protocol

Authors: K. Murakami, M. Maruyama.

Date: June 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2173

This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. MAPOS is a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. NSP automates the HDLC address configuration of each node. Using NSP, a node retrieves its HDLC address from the switch to which it is connected.

RFC 2174 A MAPOS version 1 Extension - Switch-Switch Protocol

Authors: K. Murakami, M. Maruyama.

Date: June 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2174

This document describes a MAPOS version 1 extension, SSP (SwitchSwitch Protocol). MAPOS is a multiple access protocol for transmission of network-protocol packets, encapsulated in High-LevelData Link Control (HDLC) frames, over SONET/SDH. In MAPOS network, aSONET switch provides the multiple access capability to end nodes.SSP is a protocol of Distance Vector family and provides unicast and broadcast/multicast routing for multiple SONET switch environment.

RFC 2175 MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing

Authors: K. Murakami, M. Maruyama.

Date: June 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2175

This document describes the protocol MAPOS 16, Multiple AccessProtocol over SONET/SDH with 16 Bit Addressing, for transmitting network-protocol datagrams over SONET/SDH. The primary difference with MAPOS version 1 is that it has 16 bit address field that offers significant wide address space. It first describes the major differences between MAPOS and MAPOS 16 briefly. Then, it explains the header format and its 16 bit address format.

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 2177 IMAP4 IDLE command

Authors: B. Leiba.

Date: June 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2177

This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK]

RFC 2178 OSPF Version 2

Authors: J. Moy.

Date: July 1997

Formats: txt json html

Obsoletes: RFC 1583

Obsoleted by: RFC 2328

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2178

This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree.
OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.
The differences between this memo and RFC 1583 are explained inAppendix G. All differences are backward-compatible in nature.Implementations of this memo and of RFC 1583 will interoperate.
Please send comments to ospf@gated.cornell.edu.

RFC 2179 Network Security For Trade Shows

Authors: A. Gwinn.

Date: July 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2179

This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. Generally, it has been observed that many system administrators and trade show coordinators tend to overlook the importance of system security at trade shows. In fact, systems at trade shows are at least as prone to attack as office-based platforms. Trade show systems should be treated as seriously as an office computer. A breach of security of a trade show system can render -- and has rendered -- an exhibitor's demonstrations inoperable -- sometimes for the entire event!
This document is not intended to replace the multitudes of comprehensive books on the subject of Internet security. Rather, its purpose is to provide a checklist-style collection of frequently overlooked, simple ways to minimize the chance of a costly attack.We encourage exhibitors to pay special attention to this document and share it with all associated representatives.

RFC 2180 IMAP4 Multi-Accessed Mailbox Practice

Authors: M. Gahrns.

Date: July 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2180

The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

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 2182 Selection and Operation of Secondary DNS Servers

Authors: R. Elz, R. Bush, S. Bradner, M. Patton.

Date: July 1997

Formats: txt html json

Also: BCP 0016

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2182

The Domain Name System requires that multiple servers exist for every delegated domain (zone). This document discusses the selection of secondary servers for DNS zones. Both the physical and topological location of each server are material considerations when selecting secondary servers. The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered.

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 2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations

Authors: N. Freed, K. Moore.

Date: August 1997

Formats: txt json html

Obsoleted by: RFC 2231

Updates: RFC 2045, RFC 2047, RFC 2183

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2184

This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]

RFC 2185 Routing Aspects of IPv6 Transition

Authors: R. Callon, D. Haskin.

Date: September 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2185

This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document"Transition Mechanisms for IPv6 Hosts and Routers" [1]. Readers should be familiar with the transition mechanisms before reading this document.
The proposals contained in this document are based on the work of theNgtrans working group.

RFC 2186 Internet Cache Protocol (ICP), version 2

Authors: D. Wessels, K. Claffy.

Date: September 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2186

This document describes version 2 of the Internet Cache Protocol(ICPv2) as currently implemented in two World-Wide Web proxy cache packages[3,5]. ICP is a lightweight message format used for communicating among Web caches. ICP is used to exchange hints about the existence of URLs in neighbor caches. Caches exchange ICP queries and replies to gather information to use in selecting the most appropriate location from which to retrieve an object.
This document describes only the format and fields of ICP messages.A companion document (RFC2187) describes the application of ICP toWeb caches. Several independent caching implementations now use ICP, and we consider it important to codify the existing practical uses ofICP for those trying to implement, deploy, and extend its use for their own purposes.

RFC 2187 Application of Internet Cache Protocol (ICP), version 2

Authors: D. Wessels, K. Claffy.

Date: September 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2187

This document describes the application of ICPv2 (Internet CacheProtocol version 2, RFC2186) to Web caching. ICPv2 is a lightweight message format used for communication among Web caches. Several independent caching implementations now use ICP[3,5], making it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use.
ICP queries and replies refer to the existence of URLs (or objects) in neighbor caches. Caches exchange ICP messages and use the gathered information to select the most appropriate location from which to retrieve an object. A companion document (RFC2186) describes the format and syntax of the protocol itself. In this document we focus on issues of ICP deployment, efficiency, security, and interaction with other aspects of Web traffic behavior.

RFC 2188 AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2

Authors: M. Banan, M. Taylor, J. Cheng.

Date: September 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2188

This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). The ESRO service is similar to and is consistent with other Remote Procedure Call services. The emphasis of ESRO service definition and the ESRO protocol is on efficiency. ESRO is designed specifically with wireless network (e.g., CDPD) usage in mind.
ESRO protocol provides reliable connectionless remote operation services on top of UDP (or any other non-reliable connectionless transport service) with minimum overhead. ESRO protocol supports segmentation and reassembly, concatenation and separation as well as multiplexing for service users (applications).
ESRO allows for trade-offs between efficiency and reliability by specifying both 2-way hand-shake and 3-way hand-shake based protocols.
Encoding mechanisms for presentation of the parameters of remote operations are outside the scope of this document. But, identification (tagging) of the encoding mechanism in use (e.g., XDR,
BER, PER) is supported by ESRO protocol.
A variety of applications can use the ESRO protocol. Some early applications using ESRO include efficient short message submission and delivery, credit card authorization and white pages lookup.

RFC 2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --

Authors: A. Ballardie.

Date: September 1997

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 2189

This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing.
CBT may use a separate multicast routing table, or it may use that of underlying unicast routing, to establish paths between senders and receivers. The CBT architecture is described in [1].
This document is progressing through the IDMR working group of theIETF. CBT related documents include [1, 5, 6]. For all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr.

RFC 2190 RTP Payload Format for H.263 Video Streams

Authors: C. Zhu.

Date: September 1997

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 2190

This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortestH.263 payload header (mode A) supports fragmentation at Group ofBlock (GOB) boundaries. The long H.263 payload headers (mode B and C) support fragmentation at Macroblock (MB) boundaries.

RFC 2191 VENUS - Very Extensive Non-Unicast Service

Authors: G. Armitage.

Date: September 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2191

The MARS model (RFC2022) provides a solution to intra-LIS IP multicasting over ATM, establishing and managing the use of ATM pt- mpt SVCs for IP multicast packet forwarding. Inter-LIS multicast forwarding is achieved using Mrouters, in a similar manner to which the "Classical IP over ATM" model uses Routers to inter-connect LISes for unicast traffic. The development of unicast IP shortcut mechanisms (e.g. NHRP) has led some people to request the development of a Multicast equivalent. There are a number of different approaches. This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed "Very Extensive NonUnicast Service"(VENUS), and shows how complex such a service would be. It is also noted that VENUS ultimately has the look and feel of a single, large cluster using a distributed MARS. This document is being issued to help focus ION efforts towards alternative solutions for establishingATM level multicast connections between LISes.

RFC 2192 IMAP URL Scheme

Authors: C. Newman.

Date: September 1997

Formats: txt html json

Obsoleted by: RFC 5092

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2192

IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores.This document defines a URL scheme for referencing objects on anIMAP server.

RFC 2193 IMAP4 Mailbox Referrals

Authors: M. Gahrns.

Date: September 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2193

Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]

RFC 2194 Review of Roaming Implementations

Authors: B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.

Date: September 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2194

This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC 2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response

Authors: J. Klensin, R. Catoe, P. Krumviede.

Date: September 1997

Formats: txt json html

Obsoletes: RFC 2095

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2195

While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access.This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734.

RFC 2196 Site Security Handbook

Authors: B. Fraser.

Date: September 1997

Formats: txt html json

Obsoletes: RFC 1244

Also: FYI 0008

Status: INFORMATIONAL

DOI: 10.17487/RFC 2196

This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response.

RFC 2197 SMTP Service Extension for Command Pipelining

Authors: N. Freed.

Date: September 1997

Formats: txt html json

Obsoletes: RFC 1854

Obsoleted by: RFC 2920

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2197

This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]

RFC 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 2199 Request for Comments Summary RFC Numbers 2100-2199

Authors: A. Ramos.

Date: January 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2199

RFC 2200 Internet Official Protocol Standards

Authors: J. Postel.

Date: June 1997

Formats: txt json html

Obsoletes: RFC 1250, RFC 2000

Obsoleted by: RFC 2300

Status: HISTORIC

DOI: 10.17487/RFC 2200

A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]

RFC 2201 Core Based Trees (CBT) Multicast Routing Architecture

Authors: A. Ballardie.

Date: September 1997

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 2201

CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. Most multicast algorithms build one multicast tree per sender (subnetwork), the tree being rooted at the sender's subnetwork. The primary advantage of the shared tree approach is that it typically offers more favourable scaling characteristics than all other multicast algorithms.
The CBT protocol [1] is a network layer multicast routing protocol that builds and maintains a shared delivery tree for a multicast group. The sending and receiving of multicast data by hosts on a subnetwork conforms to the traditional IP multicast service model[2].
CBT is progressing through the IDMR working group of the IETF. TheCBT protocol is described in an accompanying document [1]. For this, and all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr

RFC 2202 Test Cases for HMAC-MD5 and HMAC-SHA-1

Authors: P. Cheng, R. Glenn.

Date: September 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2202

This document provides two sets of test cases for HMAC-MD5 and HMAC-SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. Both constructs are used by IPSEC [OG,CG] and other protocols to authenticate messages.The test cases and results provided in this document are meant to be used as a conformance test for HMAC-MD5 and HMAC-SHA-1 implementations.

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 2204 ODETTE File Transfer Protocol

Authors: D. Nash.

Date: September 1997

Formats: txt json html

Obsoleted by: RFC 5024

Status: INFORMATIONAL

DOI: 10.17487/RFC 2204

This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners.
The protocol, denoted the ODETTE File Transfer Protocol, supports both direct communication between installations and indirect communication via a third party clearing centre. It was developed by the Organisation for Data Exchange by Tele Transmission in Europe to facilitate communication within the European motor industry and is presented here to allow for wider use within the Internet community.

RFC 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 2206 RSVP Management Information Base using SMIv2

Authors: F. Baker, J. Krawczyk, A. Sastry.

Date: September 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2206

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the ResourceReservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu.

RFC 2207 RSVP Extensions for IPSEC Data Flows

Authors: L. Berger, T. O'Malley.

Date: September 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2207

This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IPAuthentication Header (AH) or RFC 1827, IP Encapsulating SecurityPayload (ESP). RSVP Version 1 as currently specified can support theIPSEC protocols, but only on a per address, per protocol basis not on a per flow basis. The presented extensions can be used with bothIPv4 and IPv6.

RFC 2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment

Authors: A. Mankin, Ed., F. Baker, B. Braden, S. Bradner, M. O'Dell, A. Romanow, A. Weinrib, L. Zhang.

Date: September 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2208

This document describes the applicability of RSVP along with theIntegrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This document accompanies the first submission of RSVP and integrated services specifications onto theInternet standards track.

RFC 2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules

Authors: R. Braden, L. Zhang.

Date: September 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2209

This memo contains an algorithmic description of the rules used by anRSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification.
This memo provides a generic description of the rules for the operation of Version 1 of RSVP [RFC 2205]. It is intended to outline a set of algorithms that will accomplish the needed function, omitting many details.

RFC 2210 The Use of RSVP with IETF Integrated Services

Authors: J. Wroclawski.

Date: September 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2210

This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. TheRSVP protocol defines several data objects which carry resource reservation information but are opaque to RSVP itself. The usage and data format of those objects is given here.

RFC 2211 Specification of the Controlled-Load Network Element Service

Authors: J. Wroclawski.

Date: September 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2211

This memo specifies the network element behavior required to deliverControlled-Load service in the Internet. Controlled-load service provides the client data flow with a quality of service closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded.

RFC 2212 Specification of Guaranteed Quality of Service

Authors: S. Shenker, C. Partridge, R. Guerin.

Date: September 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2212

This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in theInternet. Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queueing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth. This specification follows the service specification template described in [1].

RFC 2213 Integrated Services Management Information Base using SMIv2

Authors: F. Baker, J. Krawczyk, A. Sastry.

Date: September 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2213

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu.

RFC 2214 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2

Authors: F. Baker, J. Krawczyk, A. Sastry.

Date: September 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2214

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the IntegratedServices Model. Comments should be made to the Integrated ServicesWorking Group, intserv@isi.edu.

RFC 2215 General Characterization Parameters for Integrated Service Network Elements

Authors: S. Shenker, J. Wroclawski.

Date: September 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2215

This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. General parameters are those with common, shared definitions across all QoS control services.

RFC 2216 Network Element Service Specification Template

Authors: S. Shenker, J. Wroclawski.

Date: September 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2216

This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. The specification template includes per-element requirements such as the service's packet handling behavior, parameters required and made available by the service, traffic specification and policing requirements, and traffic ordering relationships. It also includes evaluation criteria for elements providing the service, and examples of how the service might be implemented (by network elements) and used (by applications).

RFC 2217 Telnet Com Port Control Option

Authors: G. Clark.

Date: October 1997

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2217

This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. This memo defines an Experimental Protocol for the Internet community.

RFC 2218 A Common Schema for the Internet White Pages Service

Authors: T. Genovese, B. Jennings.

Date: October 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2218

This work is the result of the IETF Integrated Directory Services(IDS) Working Group. The IDS Working Group proposes a standard specification for a simple Internet White Pages service by defining a common schema for use by the various White Pages servers. This schema is independent of specific implementations of the White Pages service.
This document specifies the minimum set of core attributes of a WhitePages entry for an individual and describes how new objects with those attributes can be defined and published. It does not describe how to represent other objects in the White Pages service. Further, it does not address the search sort expectations within a particular service.

RFC 2219 Use of DNS Aliases for Network Services

Authors: M. Hamilton, R. Wright.

Date: October 1997

Formats: txt json html

Also: BCP 0017

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2219

It has become a common practice to use symbolic names (usuallyCNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers,Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP[RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server.
Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols.
It is important to note that these naming conventions do not provide a complete long term solution to the problem of finding a particular network service for a site. There are efforts in other IETF working groups to address the long term solution to this problem, such as theServer Location Resource Records (DNS SRV) [RFC-2052] work.

RFC 2220 The Application/MARC Content-type

Authors: R. Guenther.

Date: October 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2220

This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications.

RFC 2221 IMAP4 Login Referrals

Authors: M. Gahrns.

Date: October 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2221

When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. [STANDARDS-TRACK]

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 2224 NFS URL Scheme

Authors: B. Callaghan.

Date: October 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2224

A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined inRFC 1738, "Uniform Resource Locators (URL)".
This scheme uses the public filehandle and multi-component lookup[RFC2054, RFC2055] to access server data with a minimum of protocol overhead.
The NFS protocol provides access to shared filesystems across networks. It is designed to be machine, operating system, network architecture, and transport protocol independent. The protocol currently exists in two versions: version 2 [RFC1094] and version 3[RFC1813], both built on ONC RPC [RFC1831] at its associated eXternalData Representation (XDR) [RFC1832] and Binding Protocol [RFC1833].

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 2226 IP Broadcast over ATM Networks

Authors: T. Smith, G. Armitage.

Date: October 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2226

This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. The solution revolves around treating the broadcast problem as a special case of multicast, where every host in the subnet or cluster is a member of the group.
An understanding of the services provided by RFC 2022 is assumed.

RFC 2227 Simple Hit-Metering and Usage-Limiting for HTTP

Authors: J. Mogul, P. Leach.

Date: October 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2227

This document proposes a simple extension to HTTP, using a new "Meter" header. [STANDARDS-TRACK]

RFC 2228 FTP Security Extensions

Authors: M. Horowitz, S. Lunt.

Date: October 1997

Formats: txt json html

Updates: RFC 0959

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2228

This document defines extensions to the FTP specification STD 9, RFC959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings.
The following new optional commands are introduced in this specification:
AUTH (Authentication/Security Mechanism),ADAT (Authentication/Security Data),PROT (Data Channel Protection Level),PBSZ (Protection Buffer Size),CCC (Clear Command Channel),MIC (Integrity Protected Command),CONF (Confidentiality Protected Command), andENC (Privacy Protected Command).
A new class of reply types (6yz) is also introduced for protected replies.
None of the above commands are required to be implemented, but interdependencies exist. These dependencies are documented with the commands.
Note that this specification is compatible with STD 9, RFC 959.

RFC 2229 A Dictionary Server Protocol

Authors: R. Faith, B. Martin.

Date: October 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2229

The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases.

RFC 2230 Key Exchange Delegation Record for the DNS

Authors: R. Atkinson.

Date: November 1997

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2230

This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations

Authors: N. Freed, K. Moore.

Date: November 1997

Formats: txt json html

Obsoletes: RFC 2184

Updates: RFC 2045, RFC 2047, RFC 2183

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2231

This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK]

RFC 2232 Definitions of Managed Objects for DLUR using SMIv2

Authors: B. Clouston, Ed., B. Moore, Ed..

Date: November 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2232

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. [STANDARDS-TRACK]

RFC 2233 The Interfaces Group MIB using SMIv2

Authors: K. McCloghrie, F. Kastenholz.

Date: November 1997

Formats: txt html json

Obsoletes: RFC 1573

Obsoleted by: RFC 2863

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2233

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANDARDS-TRACK]

RFC 2234 Augmented BNF for Syntax Specifications: ABNF

Authors: D. Crocker, Ed., P. Overell.

Date: November 1997

Formats: txt json html

Obsoleted by: RFC 4234

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2234

In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]

RFC 2235 Hobbes' Internet Timeline

Authors: R. Zakon.

Date: November 1997

Formats: txt json html

Also: FYI 0032

Status: INFORMATIONAL

DOI: 10.17487/RFC 2235

This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today. A growth summary of the Internet and some associated technologies is also included. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

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 2237 Japanese Character Encoding for Internet Messages

Authors: K. Tamaru.

Date: November 1997

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2237

This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2238 Definitions of Managed Objects for HPR using SMIv2

Authors: B. Clouston, Ed., B. Moore, Ed..

Date: November 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2238

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. [STANDARDS-TRACK]

RFC 2239 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2

Authors: K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts.

Date: November 1997

Formats: txt json html

Obsoleted by: RFC 2668

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2239

This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing 10 and 100 Mb/secondMedium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30,"10 & 100 Mb/s Management," October 26, 1995.

RFC 2240 A Legal Basis for Domain Name Allocation

Authors: O. Vaughan.

Date: November 1997

Formats: txt html json

Obsoleted by: RFC 2352

Status: INFORMATIONAL

DOI: 10.17487/RFC 2240

The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2241 DHCP Options for Novell Directory Services

Authors: D. Provan.

Date: November 1997

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2241

This document defines three new DHCP options for delivering configuration information to clients of the Novell DirectoryServices. The first option carries a list of NDS servers. The second option carries the name of the client's NDS tree. The third carries the initial NDS context. These three options provide an NDS client with enough information to connect to an NDS tree without manual configuration of the client.

RFC 2242 NetWare/IP Domain Name and Information

Authors: R. Droms, K. Fong.

Date: November 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2242

This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK]

RFC 2243 OTP Extended Responses

Authors: C. Metz.

Date: November 1997

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2243

This document provides a specification for a type of response to anOTP [RFC 1938] challenge that carries explicit indication of the response's encoding. Codings for the two mandatory OTP data formats using this new type of response are presented.
This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase.

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 2245 Anonymous SASL Mechanism

Authors: C. Newman.

Date: November 1997

Formats: txt html json

Obsoleted by: RFC 4505

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2245

It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using "anonymous" as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework.

RFC 2246 The TLS Protocol Version 1.0

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 2248 Network Services Monitoring MIB

Authors: N. Freed, S. Kille.

Date: January 1998

Formats: txt html json

Obsoletes: RFC 1565

Obsoleted by: RFC 2788

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2248

This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK]

RFC 2249 Mail Monitoring MIB

Authors: N. Freed, S. Kille.

Date: January 1998

Formats: txt html json

Obsoletes: RFC 1566

Obsoleted by: RFC 2789

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2249

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS- TRACK]

RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video

Authors: D. Hoffman, G. Fernando, V. Goyal, M. Civanlar.

Date: January 1998

Formats: txt html json

Obsoletes: RFC 2038

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2250

This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF.
This memo is a revision of RFC 2038, an Internet standards track protocol. In this revision, the packet loss resilience mechanisms inSection 3.4 were extended to include additional picture header information required for MPEG2. A new section on security considerations for this payload type is added.

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 2257 Agent Extensibility (AgentX) Protocol Version 1

Authors: M. Daniele, B. Wijnen, D. Francisco.

Date: January 1998

Formats: txt json html

Obsoleted by: RFC 2741

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2257

This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK]

RFC 2258 Internet Nomenclator Project

Authors: J. Ordille.

Date: January 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2258

The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world.Each CCSO server has a database schema that is tailored to the needs of the organization that owns it. The project is integrating the different database schema into one query service. The InternetNomenclator Project will provide fast cross-server searches for locating people on the Internet. It augments existing CCSO services by supplying schema integration, more extensive indexing, and two kinds of caching -- all this in a system that scales as the number ofCCSO servers grows. One of the best things about the system is that administrators can incorporate their CCSO servers into Nomenclator without changing the servers. All Nomenclator needs is basic information about the server.
This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet NomenclatorProject, and how to use the Nomenclator search engine to find people on the Internet.

RFC 2259 Simple Nomenclator Query Protocol (SNQP)

Authors: J. Elliott, J. Ordille.

Date: January 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2259

The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. The protocol is useful to services that search many data repositories for query responses. Clients can pose queries on relations, list descriptions of relations, and obtain advice on reducing the search time and cost of their queries. Clients are informed of the age of information in caches, and may request more recent information. SNQP provides support for graphical user interfaces. It also supports different types of comparison operators, so services can use SNQP with a variety of back-end servers, e.g. relational database servers, CCSO servers, and servers providing relational views of X.500.
SNQP is an ASCII protocol in the request-reply style of SMTP. It was specifically designed for use with the Nomenclator name and information service, and has been useful elsewhere.

RFC 2260 Scalable Support for Multi-homed Multi-provider Connectivity

Authors: T. Bates, Y. Rekhter.

Date: January 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2260

This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2261 An Architecture for Describing SNMP Management Frameworks

Authors: D. Harrington, R. Presuhn, B. Wijnen.

Date: January 1998

Formats: txt html json

Obsoleted by: RFC 2271

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2261

This document describes an architecture for describing SNMPManagement Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data.

RFC 2262 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

Authors: J. Case, D. Harrington, R. Presuhn, B. Wijnen.

Date: January 1998

Formats: txt json html

Obsoleted by: RFC 2272

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2262

This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.

RFC 2263 SNMPv3 Applications

Authors: D. Levi, P. Meyer, B. Stewart.

Date: January 1998

Formats: txt json html

Obsoleted by: RFC 2273

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2263

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding.

RFC 2264 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)

Authors: U. Blumenthal, B. Wijnen.

Date: January 1998

Formats: txt html json

Obsoleted by: RFC 2274

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2264

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model.

RFC 2265 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

Authors: B. Wijnen, R. Presuhn, K. McCloghrie.

Date: January 1998

Formats: txt html json

Obsoleted by: RFC 2275

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2265

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model.

RFC 2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices

Authors: J. Flick.

Date: January 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2266

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 network repeaters based on IEEE 802.12.

RFC 2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing

Authors: P. Ferguson, D. Senie.

Date: January 1998

Formats: txt json html

Obsoleted by: RFC 2827

Status: INFORMATIONAL

DOI: 10.17487/RFC 2267

Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point.

RFC 2268 A Description of the RC2(r) Encryption Algorithm

Authors: R. Rivest.

Date: March 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2268

This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2269 Using the MARS Model in non-ATM NBMA Networks

Authors: G. Armitage.

Date: January 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2269

Initially developed for IP over ATM, the RFC 2022 (MARS) model is also applicable to other NBMA networks that provide the equivalent of switched, point to multipoint connections. This short document is intended to state the obvious equivalences, and explain the less obvious implications. No changes to the MARS model per se are suggested or required. RFC 2022 is not required over NBMA networks that offer Ethernet-like group addressing functionality.

RFC 2270 Using a Dedicated AS for Sites Homed to a Single Provider

Authors: J. Stewart, T. Bates, R. Chandra, E. Chen.

Date: January 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2270

With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930.

RFC 2271 An Architecture for Describing SNMP Management Frameworks

Authors: D. Harrington, R. Presuhn, B. Wijnen.

Date: January 1998

Formats: txt html json

Obsoletes: RFC 2261

Obsoleted by: RFC 2571

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2271

This document describes an architecture for describing SNMPManagement Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data.

RFC 2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

Authors: J. Case, D. Harrington, R. Presuhn, B. Wijnen.

Date: January 1998

Formats: txt json html

Obsoletes: RFC 2262

Obsoleted by: RFC 2572

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2272

This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.

RFC 2273 SNMPv3 Applications

Authors: D. Levi, P. Meyer, B. Stewart.

Date: January 1998

Formats: txt json html

Obsoletes: RFC 2263

Obsoleted by: RFC 2573

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2273

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding.

RFC 2274 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)

Authors: U. Blumenthal, B. Wijnen.

Date: January 1998

Formats: txt html json

Obsoletes: RFC 2264

Obsoleted by: RFC 2574

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2274

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model.

RFC 2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

Authors: B. Wijnen, R. Presuhn, K. McCloghrie.

Date: January 1998

Formats: txt html json

Obsoletes: RFC 2265

Obsoleted by: RFC 2575

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2275

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model.

RFC 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 2277 IETF Policy on Character Sets and Languages

Authors: H. Alvestrand.

Date: January 1998

Formats: txt json html

Also: BCP 0018

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2277

This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC 2278 IANA Charset Registration Procedures

Authors: N. Freed, J. Postel.

Date: January 1998

Formats: txt html json

Obsoleted by: RFC 2978

Status: INFORMATIONAL

DOI: 10.17487/RFC 2278

MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC 2279 UTF-8, a transformation format of ISO 10646

Authors: F. Yergeau.

Date: January 1998

Formats: txt html json

Obsoletes: RFC 2044

Obsoleted by: RFC 3629

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2279

ISO/IEC 10646-1 defines a multi-octet character set called theUniversal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards.

RFC 2280 Routing Policy Specification Language (RPSL)

Authors: C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, C. Villamizar.

Date: January 1998

Formats: txt html json

Obsoleted by: RFC 2622

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2280

This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]

RFC 2281 Cisco Hot Standby Router Protocol (HSRP)

Authors: T. Li, B. Cole, P. Morton, D. Li.

Date: March 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2281

The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. Multiple routers participate in this protocol and in concert create the illusion of a single virtual router. The protocol insures that one and only one of the routers is forwarding packets on behalf of the virtual router. End hosts forward their packets to the virtual router.
The router forwarding packets is known as the active router. A standby router is selected to replace the active router should it fail. The protocol provides a mechanism for determining active and standby routers, using the IP addresses on the participating routers.If an active router fails a standby router can take over without a major interruption in the host's connectivity. This memo also discusses the ARP, MAC address, and security issues with this protocol.

RFC 2282 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees

Authors: J. Galvin.

Date: February 1998

Formats: txt json html

Obsoletes: RFC 2027

Obsoleted by: RFC 2727

Status: INFORMATIONAL

DOI: 10.17487/RFC 2282

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today.

RFC 2283 Multiprotocol Extensions for BGP-4

Authors: T. Bates, R. Chandra, D. Katz, Y. Rekhter.

Date: February 1998

Formats: txt json html

Obsoleted by: RFC 2858

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2283

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]

RFC 2284 PPP Extensible Authentication Protocol (EAP)

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 2285 Benchmarking Terminology for LAN Switching Devices

Authors: R. Mandeville.

Date: February 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2285

This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128

Authors: J. Kapp.

Date: February 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2286

This document provides two sets of test cases for HMAC-RIPEMD160 andHMAC-RIPEMD128, respectively. HMAC-RIPEMD160 and HMAC-RIPEMD128 are two constructs of the HMAC [HMAC] message authentication function using the RIPEMD-160 and RIPEMD-128 [RIPE] hash functions. The test cases and results provided in this document are meant to be used as a conformance test for HMAC-RIPEMD160 and HMAC-RIPEMD128 implementations.

RFC 2287 Definitions of System-Level Managed Objects for Applications

Authors: C. Krupczak, J. Saperia.

Date: February 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2287

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. [STANDARDS-TRACK]

RFC 2288 Using Existing Bibliographic Identifiers as Uniform Resource Names

Authors: C. Lynch, C. Preston, R. Daniel.

Date: February 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2288

A system for Uniform Resource Names (URNs) must be capable of supporting identifiers from existing widely-used naming systems.This document discusses how three major bibliographic identifiers(the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs.

RFC 2289 A One-Time Password System

Authors: N. Haller, C. Metz, P. Nesser, M. Straw.

Date: February 1998

Formats: txt html json

Obsoletes: RFC 1938

Also: STD 0061

Status: INTERNET STANDARD

DOI: 10.17487/RFC 2289

This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. [STANDARDS- TRACK]

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 2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web

Authors: J. Slein, F. Vitali, E. Whitehead, D. Durand.

Date: February 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2291

Current World Wide Web (WWW or Web) standards provide simple support for applications which allow remote editing of typed data. In practice, the existing capabilities of the WWW have proven inadequate to support efficient, scalable remote editing free of overwriting conflicts. This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW.

RFC 2292 Advanced Sockets API for IPv6

Authors: W. Stevens, M. Thomas.

Date: February 1998

Formats: txt json html

Obsoleted by: RFC 3542

Status: INFORMATIONAL

DOI: 10.17487/RFC 2292

Specifications are in progress for changes to the sockets API to support IP version 6 [RFC-2133]. These changes are for TCP and UDP- based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like.
But another class of applications exists that will also be run underIPv6. We call these "advanced" applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them "advanced" is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features.
There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [RFC-2133]: Hop-by-Hop options, Destination options, and the Routing header (source routing). This document provides API access to these features too.

RFC 2293 Representing Tables and Subtrees in the X.500 Directory

Authors: S. Kille.

Date: March 1998

Formats: txt json html

Obsoletes: RFC 1837

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2293

This document defines techniques for representing two types of information mapping in the OSI Directory [1].
1. Mapping from a key to a value (or set of values), as might be done in a table lookup.
2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree.
These techniques were developed for supporting MHS use of Directory[2], but are specified separately as they have more general applicability.

RFC 2294 Representing the O/R Address hierarchy in the X.500 Directory Information Tree

Authors: S. Kille.

Date: March 1998

Formats: txt html json

Obsoletes: RFC 1836

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2294

This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This is useful for a range of purposes, including: o Support for MHS Routing [4]. o Support for X.400/RFC 822 address mappings [2, 5].
Please send comments to the author or to the discussion group <mhs- ds@mercury.udev.cdc.com&rt;.
Object Class Mandatory------------ --------- mHSCountry M aDMD M pRMD O mHSX121 O mHSNumericUserIdentifier O mHSOrganization O mHSOrganizationalUnit O mHSPerson O mHSNamedObject O mHSTerminalID O mHSDomainDefinedAttribute O
Table 1: Order of O/R Address Directory Components

RFC 2295 Transparent Content Negotiation in HTTP

Authors: K. Holtman, A. Mutz.

Date: March 1998

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2295

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

RFC 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0

Authors: K. Holtman, A. Mutz.

Date: March 1998

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 2296

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

RFC 2297 Ipsilon's General Switch Management Protocol Specification Version 2.0

Authors: P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall.

Date: March 1998

Formats: txt json html

Updates: RFC 1987

Status: INFORMATIONAL

DOI: 10.17487/RFC 2297

This memo specifies enhancements to the General Switch ManagementProtocol (GSMP) [RFC1987]. The major enhancement is the addition ofQuality of Service (QoS) messages. Other improvements have been made to the protocol resulting from operational experience. GSMP is a general purpose protocol to control an ATM switch. It allows a controller to establish and release connections across the switch; add and delete leaves on a multicast connection; manage switch ports; request configuration information; and request statistics.

RFC 2298 An Extensible Message Format for Message Disposition Notifications

Authors: R. Fajman.

Date: March 1998

Formats: txt html json

Obsoleted by: RFC 3798

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2298

This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message DispositionNotifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary"LAN-based" systems, and often referred to as "read receipts,""acknowledgements," or "receipt notifications." The intention is to do this while respecting the privacy concerns that have often been expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail.

RFC 2299 Request for Comments Summary

Authors: A. Ramos.

Date: January 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2299

RFC 2300 Internet Official Protocol Standards

Authors: J. Postel.

Date: May 1998

Formats: txt html json

Obsoletes: RFC 2200

Obsoleted by: RFC 2400

Status: HISTORIC

DOI: 10.17487/RFC 2300

A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]

RFC 2301 File Format for Internet Fax

Authors: L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty.

Date: March 1998

Formats: txt html json

Obsoleted by: RFC 3949

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2301

This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG modes (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed RasterContent modes (Profiles C, L, M) for color and grayscale fax. These modes or profiles correspond to the content of the applicable ITU-TRecommendations. Files formatted according to this specification use the image/tiff MIME Content Type.

RFC 2302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration

Authors: G. Parsons, J. Rafferty, S. Zilles.

Date: March 1998

Formats: txt json html

Obsoleted by: RFC 3302

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2302

This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK]

RFC 2303 Minimal PSTN address format in Internet Mail

Authors: C. Allocchio.

Date: March 1998

Formats: txt json html

Obsoleted by: RFC 3191

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2303

This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK]

RFC 2304 Minimal FAX address format in Internet Mail

Authors: C. Allocchio.

Date: March 1998

Formats: txt html json

Obsoleted by: RFC 3192

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2304

This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS- TRACK]

RFC 2305 A Simple Mode of Facsimile Using Internet Mail

Authors: K. Toyoda, H. Ohno, J. Murai, D. Wing.

Date: March 1998

Formats: txt html json

Obsoleted by: RFC 3965

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2305

This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK]

RFC 2306 Tag Image File Format (TIFF) - F Profile for Facsimile

Authors: G. Parsons, J. Rafferty.

Date: March 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2306

This document describes in detail the definition of TIFF-F that is used to store facsimile images. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2307 An Approach for Using LDAP as a Network Information Service

Authors: L. Howard.

Date: March 1998

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2307

This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 [X500] entries so that they may be resolved with the Lightweight DirectoryAccess Protocol [RFC2251]. A set of attribute types and object classes are proposed, along with specific guidelines for interpreting them.
The intention is to assist the deployment of LDAP as an organizational nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. The proposed mechanism has already been implemented with some success.

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 2310 The Safe Response Header Field

Authors: K. Holtman.

Date: April 1998

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 2310

This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way.

RFC 2311 S/MIME Version 2 Message Specification

Authors: S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka.

Date: March 1998

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 2311

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2312 S/MIME Version 2 Certificate Handling

Authors: S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.

Date: March 1998

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 2312

This memo describes the mechanisms S/MIME uses to create and validate keys using certificates. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2313 PKCS #1: RSA Encryption Version 1.5

Authors: B. Kaliski.

Date: March 1998

Formats: txt json html

Obsoleted by: RFC 2437

Status: INFORMATIONAL

DOI: 10.17487/RFC 2313

This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2314 PKCS #10: Certification Request Syntax Version 1.5

Authors: B. Kaliski.

Date: March 1998

Formats: txt html json

Obsoleted by: RFC 2986

Status: INFORMATIONAL

DOI: 10.17487/RFC 2314

This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2315 PKCS #7: Cryptographic Message Syntax Version 1.5

Authors: B. Kaliski.

Date: March 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2315

This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2316 Report of the IAB Security Architecture Workshop

Authors: S. Bellovin.

Date: April 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2316

On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2317 Classless IN-ADDR.ARPA delegation

Authors: H. Eidnes, G. de Groot, P. Vixie.

Date: March 1998

Formats: txt json html

Also: BCP 0020

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2317

This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC 2318 The text/css Media Type

Authors: H. Lie, B. Bos, C. Lilley.

Date: March 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2318

Cascading Style Sheets (CSS) is a style sheet language for the WorldWide Web. CSS style sheets have been in use since October 1995 using the Media Type text/css without registration; this memo seeks to regularize that position.

RFC 2319 Ukrainian Character Set KOI8-U

Authors: KOI8-U Working Group.

Date: April 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2319

This document provides information about character encoding KOI8-U(KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. KOI8-U is compatible with KOI8-R (RFC 1489) in allRussian letters and extends it with four Ukrainian letters which locations are compliant with ISO-IR-111. The official site of KOI8-UWorking Group is http://www.net.ua.

RFC 2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)

Authors: M. Greene, J. Luciani, K. White, T. Kuo.

Date: April 1998

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2320

The purpose of this memo is to define the Management Information Base(MIB) for supporting Classical IP and ARP over ATM as specified inClassical IP and ARP over ATM, refer to reference [3]. Support of anATM interface by an IP layer will require implementation of objects from several Management Information Bases (MIBs) as well as their enhancement in order to enable usage of ATM transports. It is the intent of this MIB to fully adhere to all prerequisite MIBs unless explicitly stated. Deviations will be documented in corresponding conformance statements. The specification of this MIB will utilize the Structure of Management Information (SMI) for Version 2 of theSimple Network Management Protocol Version (refer to RFC 1902, reference [1]).

RFC 2321 RITA -- The Reliable Internetwork Troubleshooting Agent

Authors: A. Bressen.

Date: 1 April 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2321

A Description of the usage of Nondeterministic Troubleshooting andDiagnostic Methodologies as applied to today's complex nondeterministic networks and environments.

RFC 2322 Management of IP numbers by peg-dhcp

Authors: K. van den Hout, A. Koopal, R. van Mook.

Date: 1 April 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2322

This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2323 IETF Identification and Security Guidelines

Authors: A. Ramos.

Date: 1 April 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2323

This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

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 2325 Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2

Authors: M. Slavitch.

Date: 1 April 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2325

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2326 Real Time Streaming Protocol (RTSP)

Authors: H. Schulzrinne, A. Rao, R. Lanphier.

Date: April 1998

Formats: txt json html

Obsoleted by: RFC 7826

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2326

The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889).

RFC 2327 SDP: Session Description Protocol

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 2329 OSPF Standardization Report

Authors: J. Moy.

Date: April 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2329

This memo documents how the requirements for advancing a routing protocol to Full Standard, set out in [Ref2], have been met forOSPFv2.
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 2331 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update

Authors: M. Maher.

Date: April 1998

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2331

This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 [SIG40] to support IP over ATM environments as described in RFC 2225 [LAUB98] and in RFC 2332 [LUC98]. Among the new features found in UNISignalling 4.0 are Available Bit Rate signalling and traffic parameter negotiation. This memo highlights the features of UNISignalling 4.0 that provide IP entities capabilities for requestingATM service in sites with SVC support, whether it is private ATM or publicly provisioned ATM, in which case the SVC support is probably configured inside PVPs.
This document is only relevant to IP when used as the well known"best effort" connectionless service. In particular, this means that this document does not pertain to IP in the presence of implementedIP Integrated Services. The topic of IP with Integrated Services over ATM will be handled by a different specification or set of specifications being worked on in the ISSLL WG.
This specification is a follow-on to RFC 1755, "ATM Signaling Support for IP over ATM", which is based on UNI 3.1 signalling [UNI95].Readers are assumed to be familiar with RFC 1755.

RFC 2332 NBMA Next Hop Resolution Protocol (NHRP)

Authors: J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy.

Date: April 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2332

This document describes the NBMA Next Hop Resolution Protocol (NHRP).NHRP can be used by a source station (host or router) connected to aNon-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the"NBMA next hop" towards a destination station. If the destination is connected to the NBMA subnetwork, then the NBMA next hop is the destination station itself. Otherwise, the NBMA next hop is the egress router from the NBMA subnetwork that is "nearest" to the destination station. NHRP is intended for use in a multiprotocol internetworking layer environment over NBMA subnetworks.
Note that while this protocol was developed for use with NBMA subnetworks, it is possible, if not likely, that it will be applied to BMA subnetworks as well. However, this usage of NHRP is for further study.
This document is intended to be a functional superset of the NBMAAddress Resolution Protocol (NARP) documented in [1].
Operation of NHRP as a means of establishing a transit path across anNBMA subnetwork between two routers will be addressed in a separate document (see [13]).

RFC 2333 NHRP Protocol Applicability Statement

Authors: D. Cansever.

Date: April 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2333

As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol(NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access(NBMA) networks, such as ATM, SMDS and X.25.

RFC 2334 Server Cache Synchronization Protocol (SCSP)

Authors: J. Luciani, G. Armitage, J. Halpern, N. Doraswamy.

Date: April 1998

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2334

This document describes the Server Cache Synchronization Protocol(SCSP) and is written in terms of SCSP's use within Non BroadcastMultiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. SCSP attempts to solve the generalized cache synchronization/cache-replication problem for distributed protocol entities. However, in this document, SCSP is couched in terms of the client/server paradigm in which distributed server entities, which are bound to a Server Group (SG) through some means, wish to synchronize the contents (or a portion thereof) of their caches which contain information about the state of clients being served.

RFC 2335 A Distributed NHRP Service Using SCSP

Authors: J. Luciani.

Date: April 1998

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2335

This document describes a method for distributing an NHRP service within a LIS [1]. This method uses the Server Cache SynchronizationProtocol (SCSP) [2] to synchronize the client information databases held by NHRP Servers (NHSs) within a LIS.

RFC 2336 Classical IP and ARP over ATM to NHRP Transition

Authors: J. Luciani.

Date: July 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2336

This document describes methods and procedures for the graceful transition from an ATMARP LIS[1] to an NHRP LIS[2] network model overATM.

RFC 2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM

Authors: D. Farinacci, D. Meyer, Y. Rekhter.

Date: April 1998

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2337

This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

RFC 2338 Virtual Router Redundancy Protocol

Authors: S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem.

Date: April 1998

Formats: txt html json

Obsoleted by: RFC 3768

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2338

This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on aLAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.

RFC 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc

Authors: in the matter of NFS V.4 Protocols. The Internet Society, Sun Microsystems.

Date: May 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2339

This Request for Comments records an agreement between SunMicrosystems, Inc. and the Internet Society to permit the flow ofSun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force.

RFC 2340 Nortel's Virtual Network Switching (VNS) Overview

Authors: B. Jamoussi, D. Jamieson, D. Williston, S. Gabe.

Date: May 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2340

This document provides an overview of Virtual Network Switching(VNS).
VNS is a multi-protocol switching architecture that provides COS- sensitive packet switching, reduces the complexity of operating protocols like PPP and frame relay, provides logical networks and traffic segregation for Virtual Private Networks (VPNs), security and traffic engineering, enables efficient WAN broadcasting and multicasting, and reduces address space requirements. VNS reduces the number of routing hops over the WAN by switching packets based on labels.
VNS has been proven in production networks for several years.

RFC 2341 Cisco Layer Two Forwarding (Protocol) "L2F"

Authors: A. Valencia, M. Littlewood, T. Kolar.

Date: May 1998

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 2341

Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, AccessServers, and ISDN routers. Previous RFCs have specified protocols for supporting IP dial-up via SLIP [1] and multiprotocol dial-up viaPPP [2]. This document describes the Layer Two Forwarding protocol(L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. Using such tunnels, it is possible to divorce the location of the initial dial- up server from the location at which the dial-up protocol connection is terminated and access to the network provided.

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 2343 RTP Payload Format for Bundled MPEG

Authors: M. Civanlar, G. Cash, B. Haskell.

Date: May 1998

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2343

This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. Bundling has some advantages for this payload type particularly when it is used for video-on-demand applications. This payload type may be used when its advantages are important enough to sacrifice the modularity of having separate audio and video streams.

RFC 2344 Reverse Tunneling for Mobile IP

Authors: G. Montenegro, Ed..

Date: May 1998

Formats: txt json html

Obsoleted by: RFC 3024

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2344

Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address.When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent.
This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address.

RFC 2345 Domain Names and Company Name Retrieval

Authors: J. Klensin, T. Wolf, G. Oglesby.

Date: May 1998

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2345

Location of web information for particular companies based on their names has become an increasingly difficult problem as the Internet and the web grow. The use of a naming convention and the domain name system (DNS) for that purpose has caused complications for the latter while not solving the problem. While there have been several proposals to use contemporary, high-capability, directory service and search protocols to reduce the dependencies on DNS conventions, none of them have been significantly deployed.
This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed.

RFC 2346 Making Postscript and PDF International

Authors: J. Palme.

Date: May 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2346

Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable DocumentFormat (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document. The commonly used paper format is different in North America and the rest of the world.North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format. This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. By using the advice in this document, you can put up a document on theInternet, which recipients can print without problem both in and outside North America.
A very short summary of the advice in this document: If you are usingU.S. Letter paper format, ensure that both the left and right margins are at least 21 mm (0.8 in). If you are using A4 paper format, ensure that both the top and bottom margins are at least 33 mm (1.3 in).

RFC 2347 TFTP Option Extension

Authors: G. Malkin, A. Harkin.

Date: May 1998

Formats: txt html json

Obsoletes: RFC 1782

Updates: RFC 1350

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2347

The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.

RFC 2348 TFTP Blocksize Option

Authors: G. Malkin, A. Harkin.

Date: May 1998

Formats: txt json html

Obsoletes: RFC 1783

Updates: RFC 1350

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2348

The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the booting of diskless nodes on a Local Area Network. TFTP is used because it is very simple to implement in a small node's limited ROM space. However, the choice of a 512-octet blocksize is not the most efficient for use on a LAN whose MTU may 1500 octets or greater.
This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. The TFTP Option Extension mechanism is described in [2].

RFC 2349 TFTP Timeout Interval and Transfer Size Options

Authors: G. Malkin, A. Harkin.

Date: May 1998

Formats: txt json html

Obsoletes: RFC 1784

Updates: RFC 1350

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2349

The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.
This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. The TFTP Option Extension mechanism is described in [2].

RFC 2350 Expectations for Computer Security Incident Response

Authors: N. Brownlee, E. Guttman.

Date: June 1998

Formats: txt json html

Also: BCP 0021

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2350

The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams(CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities.
CSIRT constituents have a legitimate need and right to fully understand the policies and procedures of 'their' Computer SecurityIncident Response Team. One way to support this understanding is to supply detailed information which users may consider, in the form of a formal template completed by the CSIRT. An outline of such a template and a filled in example are provided.

RFC 2351 Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP

Authors: A. Robert.

Date: May 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2351

This memo specifies a protocol for the encapsulation of the airline specific protocol over IP.

RFC 2352 A Convention For Using Legal Names as Domain Names

Authors: O. Vaughan.

Date: May 1998

Formats: txt html json

Obsoletes: RFC 2240

Status: INFORMATIONAL

DOI: 10.17487/RFC 2352

The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document

Authors: G. Dudley.

Date: May 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2353

This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2354 Options for Repair of Streaming Media

Authors: C. Perkins, O. Hodson.

Date: June 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2354

This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. The techniques discussed include redundant transmission, retransmission, interleaving and forward error correction. The range of applicability of these techniques is noted, together with the protocol requirements and dependencies.

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 2356 Sun's SKIP Firewall Traversal for Mobile IP

Authors: G. Montenegro, V. Gupta.

Date: June 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2356

The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. Mobility implies higher security risks than static operation, because the traffic may at times take unforeseen network paths with unknown or unpredictable security characteristics. The Mobile IP specification makes no provisions for securing data traffic. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network.
In addition to securing traffic, our mechanisms allow a mobile node to roam into regions that (1) impose ingress filtering, and (2) use a different address space.

RFC 2357 IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols

Authors: A. Mankin, A. Romanow, S. Bradner, V. Paxson.

Date: June 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2357

This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of theIETF. Within today's Internet, important applications exist for a reliable multicast service. Some examples that are driving reliable multicast technology are collaborative workspaces (such as whiteboard), data and software distribution, and (more speculatively) web caching protocols. Due to the nature of the technical issues, a single commonly accepted technical solution that solves all the demands for reliable multicast is likely to be infeasible [RMMinutes1997].
A number of reliable multicast protocols have already been developed to solve a variety of problems for various types of applications.[Floyd97] describes one widely deployed example. How should these protocols be treated within the IETF and how should the IETF guide the development of reliable multicast in a direction beneficial for the general Internet?
The TSV Area Directors and their Directorate have outlined a set of review procedures that address these questions and set criteria and processes for the publication as RFCs of Internet-Drafts on reliable multicast transport protocols.

RFC 2358 Definitions of Managed Objects for the Ethernet-like Interface Types

Authors: J. Flick, J. Johnson.

Date: June 1998

Formats: txt json html

Obsoletes: RFC 1650

Obsoleted by: RFC 2665

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2358

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1650 "Definitions of Managed Objects for theEthernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflect a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology.

RFC 2359 IMAP4 UIDPLUS extension

Authors: J. Myers.

Date: June 1998

Formats: txt json html

Obsoleted by: RFC 4315

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2359

The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK]

RFC 2360 Guide for Internet Standards Writers

Authors: G. Scott.

Date: June 1998

Formats: txt json html

Also: BCP 0022

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2360

This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. In addition, it singles out usage believed to have led to unclear specifications, resulting in non-interoperable interpretations in the past. These guidelines are to be used withRFC 2223, "Instructions to RFC Authors".

RFC 2361 WAVE and AVI Codec Registries

Authors: E. Fleischman.

Date: June 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2361

Internet applications may reference specific codecs within the WAVE and AVI registries as follows:* video/vnd.avi; codec=XXX identifies a specific video codec (i.e.,XXX) within the AVI Registry.* audio/vnd.wave; codec=YYY identifies a specific audio codec(i.e., YYY) within the WAVE Registry.
Appendix A and Appendix B provides an authoritative reference for the interpretation of the required "codec" parameter. That is, the current set of audio codecs that are registered within the WAVERegistry are enumerated in Appendix A. Appendix B enumerates the current set of video codecs that have been registered to date within the AVI Registry.

RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification

Authors: D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei.

Date: June 1998

Formats: txt html json

Obsoletes: RFC 2117

Obsoleted by: RFC 4601, RFC 5059

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2362

This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

RFC 2363 PPP Over FUNI

Authors: G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens.

Date: July 1998

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2363

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of ATM Frame User Network Interface(FUNI) for framing PPP encapsulated packets.

RFC 2364 PPP Over AAL5

Authors: G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens.

Date: July 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2364

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets.

RFC 2365 Administratively Scoped IP Multicast

Authors: D. Meyer.

Date: July 1998

Formats: txt json html

Also: BCP 0023

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2365

This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC 2366 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks

Authors: C. Chung, M. Greene.

Date: July 1998

Formats: txt html json

Obsoleted by: RFC 2417

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2366

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI3.0/3.1 based ATM Networks' [1].
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community.

RFC 2367 PF_KEY Key Management API, Version 2

Authors: D. McDonald, C. Metz, B. Phan.

Date: July 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2367

A generic key management API that can be used not only for IPSecurity [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of thisAPI was implemented inside 4.4-Lite BSD as part of the U. S. NavalResearch Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], aPhoturis daemon, or a SKIP certificate discovery protocol daemon).

RFC 2368 The mailto URL scheme

Authors: P. Hoffman, L. Masinter, J. Zawinski.

Date: July 1998

Formats: txt json html

Obsoleted by: RFC 6068

Updates: RFC 1738, RFC 1808

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2368

This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. It is one of a suite of documents which replace RFC 1738, 'Uniform Resource Locators', andRFC 1808, 'Relative Uniform Resource Locators'. The syntax of'mailto' URLs from RFC 1738 is extended to allow creation of more RFC822 messages by allowing the URL to express additional header and body fields.

RFC 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields

Authors: G. Neufeld, J. Baer.

Date: July 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2369

The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. Each field typically contains a URL (usually mailto [RFC2368]) locating the relevant information or performing the command directly. The three core header fields described in this document are List-Help, List-Subscribe, and List-Unsubscribe.
There are three other header fields described here which, although not as widely applicable, will have utility for a sufficient number of mailing lists to justify their formalization here. These areList-Post, List-Owner and List-Archive.
By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands.

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 2371 Transaction Internet Protocol Version 3.0

Authors: J. Lyon, K. Evans, J. Klein.

Date: July 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2371

In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end.

RFC 2372 Transaction Internet Protocol - Requirements and Supplemental Information

Authors: K. Evans, J. Klein, J. Lyon.

Date: July 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2372

This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol [1]. It is intended to help qualify the necessary features and functions of the protocol. It also provides supplemental information to aid understanding and facilitate implementation of the TIP protocol.

RFC 2373 IP Version 6 Addressing Architecture

Authors: R. Hinden, S. Deering.

Date: July 1998

Formats: txt html json

Obsoletes: RFC 1884

Obsoleted by: RFC 3513

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2373

This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses.

RFC 2374 An IPv6 Aggregatable Global Unicast Address Format

Authors: R. Hinden, M. O'Dell, S. Deering.

Date: July 1998

Formats: txt json html

Obsoletes: RFC 2073

Obsoleted by: RFC 3587

Status: HISTORIC

DOI: 10.17487/RFC 2374

This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK]

RFC 2375 IPv6 Multicast Address Assignments

Authors: R. Hinden, S. Deering.

Date: July 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2375

This document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2376 XML Media Types

Authors: E. Whitehead, M. Murata.

Date: July 1998

Formats: txt html json

Obsoleted by: RFC 3023

Status: INFORMATIONAL

DOI: 10.17487/RFC 2376

This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the WorldWide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.

RFC 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 2378 The CCSO Nameserver (Ph) Architecture

Authors: R. Hedberg, P. Pomes.

Date: September 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2378

The Ph Nameserver from the Computing and Communications ServicesOffice (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. The Ph service as specified in this document is built around an information model, a client command language and the server responses.

RFC 2379 RSVP over ATM Implementation Guidelines

Authors: L. Berger.

Date: August 1998

Formats: txt json html

Also: BCP 0024

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2379

This memo presents specific implementation guidelines for runningRSVP over ATM switched virtual circuits (SVCs). The general problem is discussed in [6]. Implementation requirements are discussed in[2]. Integrated Services to ATM service mappings are covered in [3].The full set of documents present the background and information needed to implement Integrated Services and RSVP over ATM.

RFC 2380 RSVP over ATM Implementation Requirements

Authors: L. Berger.

Date: August 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2380

This memo presents specific implementation requirements for runningRSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. A separate document [5] provides specific guidelines for running over today's ATM networks. The general problem is discussed in [9]. Integrated Services to ATM service mappings are covered in [6]. The full set of documents present the background and information needed to implement Integrated Services and RSVP overATM.

RFC 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM

Authors: M. Garrett, M. Borden.

Date: August 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2381

This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. The service mappings are useful for providing effective interoperation and end-to-end Quality of Service for IPIntegrated Services networks containing ATM subnetworks.
The discussion and specifications given here support the IP integrated services protocols for Guaranteed Service (GS),Controlled-Load Service (CLS) and the ATM Forum UNI specification, versions 3.0, 3.1 and 4.0. Some discussion of IP best effort service over ATM is also included.

RFC 2382 A Framework for Integrated Services and RSVP over ATM

Authors: E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk.

Date: August 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2382

This document outlines the issues and framework related to providingIP Integrated Services with RSVP over ATM. It provides an overall approach to the problem(s) and related issues. These issues and problems are to be addressed in further documents from the ISATM subgroup of the ISSLL working group.

RFC 2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version

Authors: M. Suzuki.

Date: August 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2383

This document specifies an ATM-based protocol for communication between ST2+ agents. The ST2+ over ATM protocol supports the matching of one hop in an ST2+ tree-structure stream with one ATM connection.In this document, ATM is a subnet technology for the ST2+ stream.
The ST2+ over ATM protocol is designed to achieve resource- reservation communications across ATM and non-ATM networks, to extend the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ signaling limitations.
The specifications of the ST2+ over ATM protocol consist of a revision of RFC 1819 ST2+ and specifications of protocol interaction between ST2+ and ATM on the user plane, management plane, and control plane which correspond to the three planes of the B-ISDN protocol reference model.

RFC 2384 POP URL Scheme

Authors: R. Gellens.

Date: August 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2384

This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]

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 2386 A Framework for QoS-based Routing in the Internet

Authors: E. Crawley, R. Nair, B. Rajagopalan, H. Sandick.

Date: August 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2386

This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2387 The MIME Multipart/Related Content-type

Authors: E. Levinson.

Date: August 1998

Formats: txt html json

Obsoletes: RFC 2112

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2387

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use.

RFC 2388 Returning Values from Forms: multipart/form-data

Authors: L. Masinter.

Date: August 1998

Formats: txt json html

Obsoleted by: RFC 7578

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2388

This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK]

RFC 2389 Feature negotiation mechanism for the File Transfer Protocol

Authors: P. Hethmon, R. Elz.

Date: August 1998

Formats: txt json html

Also: RFC 0959

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2389

The File Transfer Protocol is, from time to time, extended with new commands, or facilities. Implementations of the FTP protocol cannot be assumed to all immediately implement all newly defined mechanisms.This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server.

RFC 2390 Inverse Address Resolution Protocol

Authors: T. Bradley, C. Brown, A. Malis.

Date: September 1998

Formats: txt json html

Obsoletes: RFC 1293

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2390

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]

RFC 2391 Load Sharing using IP Network Address Translation (LSNAT)

Authors: P. Srisuresh, D. Gan.

Date: August 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2391

Network Address Translators (NATs) translate IP addresses in a datagram, transparent to end nodes, while routing the datagram. NATs have traditionally been been used to allow private network domains to connect to Global networks using as few as one globally unique IP address. In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server. Load sharing is beneficial to service providers and system administrators alike in grappling with scalability of servers with increasing session load.

RFC 2392 Content-ID and Message-ID Uniform Resource Locators

Authors: E. Levinson.

Date: August 1998

Formats: txt html json

Obsoletes: RFC 2111

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2392

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message.

RFC 2393 IP Payload Compression Protocol (IPComp)

Authors: A. Shacham, R. Monsour, R. Pereira, M. Thomas.

Date: December 1998

Formats: txt html json

Obsoleted by: RFC 3173

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2393

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment.

RFC 2394 IP Payload Compression Using DEFLATE

Authors: R. Pereira.

Date: December 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2394

This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of theDEFLATE algorithm to the IP Payload Compression Protocol.

RFC 2395 IP Payload Compression Using LZS

Authors: R. Friend, R. Monsour.

Date: December 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2395

This document describes a compression method based on the LZS compression algorithm. This document defines the application of theLZS algorithm to the IP Payload Compression Protocol [IPCOMP].[IPCOMP] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams.

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 2397 The "data" URL scheme

Authors: L. Masinter.

Date: August 1998

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2397

A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK]

RFC 2398 Some Testing Tools for TCP Implementors

Authors: S. Parker, C. Schmechel.

Date: August 1998

Formats: txt json html

Also: FYI 0033

Status: INFORMATIONAL

DOI: 10.17487/RFC 2398

This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC 2399 Request for Comments Summary

Authors: A. Ramos.

Date: January 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2399

RFC 2400 Internet Official Protocol Standards

Authors: J. Postel, J. Reynolds.

Date: September 1998

Formats: txt json html

Obsoletes: RFC 2300

Obsoleted by: RFC 2500

Status: HISTORIC

DOI: 10.17487/RFC 2400

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK]

RFC 2401 Security Architecture for the Internet Protocol

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 2402 IP Authentication Header

Authors: S. Kent, R. Atkinson.

Date: November 1998

Formats: txt html json

Obsoletes: RFC 1826

Obsoleted by: RFC 4302, RFC 4305

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2402

The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. [STANDARDS-TRACK]

RFC 2403 The Use of HMAC-MD5-96 within ESP and AH

Authors: C. Madson, R. Glenn.

Date: November 1998

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2403

This memo describes the use of the HMAC algorithm [RFC-2104] in conjunction with the MD5 algorithm [RFC-1321] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload[ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides data origin authentication and integrity protection.
Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].

RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH

Authors: C. Madson, R. Glenn.

Date: November 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2404

This memo describes the use of the HMAC algorithm [RFC-2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC EncapsulatingSecurity Payload [ESP] and the revised IPSEC Authentication Header[AH]. HMAC with SHA-1 provides data origin authentication and integrity protection.
Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].

RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV

Authors: C. Madson, N. Doraswamy.

Date: November 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2405

This document describes the use of the DES Cipher algorithm in CipherBlock Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating SecurityPayload (ESP).

RFC 2406 IP Encapsulating Security Payload (ESP)

Authors: S. Kent, R. Atkinson.

Date: November 1998

Formats: txt html json

Obsoletes: RFC 1827

Obsoleted by: RFC 4303, RFC 4305

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2406

The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK]

RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP

Authors: D. Piper.

Date: November 1998

Formats: txt html json

Obsoleted by: RFC 4306

Status: HISTORIC

DOI: 10.17487/RFC 2407

This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK]

RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP)

Authors: D. Maughan, M. Schertler, M. Schneider, J. Turner.

Date: November 1998

Formats: txt json html

Obsoleted by: RFC 4306

Status: HISTORIC

DOI: 10.17487/RFC 2408

This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and KeyManagement Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management ofSecurity Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications(via IP Security Service or any other security protocol) in anInternet environment.

RFC 2409 The Internet Key Exchange (IKE)

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 2410 The NULL Encryption Algorithm and Its Use With IPsec

Authors: R. Glenn, S. Kent.

Date: November 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2410

This memo defines the NULL encryption algorithm and its use with theIPsec Encapsulating Security Payload (ESP). NULL does nothing to alter plaintext data. In fact, NULL, by itself, does nothing. NULL provides the means for ESP to provide authentication and integrity without confidentiality.
Further information on the other components necessary for ESP implementations is provided by [ESP] and [ROAD].

RFC 2411 IP Security Document Roadmap

Authors: R. Thayer, N. Doraswamy, R. Glenn.

Date: November 1998

Formats: txt json html

Obsoleted by: RFC 6071

Status: INFORMATIONAL

DOI: 10.17487/RFC 2411

The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. Several documents are used to describe this protocol suite. The interrelationship and organization of the various documents covering the IPsec protocol are discussed here. An explanation of what to find in which document, and what to include in new Encryption Algorithm and AuthenticationAlgorithm documents are described.

RFC 2412 The OAKLEY Key Determination Protocol

Authors: H. Orman.

Date: November 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2412

This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material.The basic mechanism is the Diffie-Hellman key exchange algorithm.
The OAKLEY protocol supports Perfect Forward Secrecy, compatibility with the ISAKMP protocol for managing security associations, user- defined abstract group structures for use with the Diffie-Hellman algorithm, key updates, and incorporation of keys distributed via out-of-band mechanisms.

RFC 2413 Dublin Core Metadata for Resource Discovery

Authors: S. Weibel, J. Kunze, C. Lagoze, M. Wolf.

Date: September 1998

Formats: txt html json

Obsoleted by: RFC 5013

Status: INFORMATIONAL

DOI: 10.17487/RFC 2413

This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community.

RFC 2414 Increasing TCP's Initial Window

Authors: M. Allman, S. Floyd, C. Partridge.

Date: September 1998

Formats: txt json html

Obsoleted by: RFC 3390

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2414

This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This document discusses the advantages and disadvantages of such a change, outlining experimental results that indicate the costs and benefits of such a change to TCP.

RFC 2415 Simulation Studies of Increased Initial TCP Window Size

Authors: K. Poduri, K. Nichols.

Date: September 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2415

An increase in the permissible initial window size of a TCP connection, from one segment to three or four segments, has been under discussion in the tcp-impl working group. This document covers some simulation studies of the effects of increasing the initial window size of TCP. Both long-lived TCP connections (file transfers) and short-lived web-browsing style connections were modeled. The simulations were performed using the publicly available ns-2 simulator and our custom models and files are also available.

RFC 2416 When TCP Starts Up With Four Packets Into Only Three Buffers

Authors: T. Shepard, C. Partridge.

Date: September 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2416

This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet).

RFC 2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks

Authors: C. Chung, M. Greene.

Date: September 1998

Formats: txt html json

Obsoletes: RFC 2366

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2417

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI3.0/3.1 based ATM Networks' [1].
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

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 2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis)

Authors: K. Sklower, G. Meyer.

Date: September 1998

Formats: txt json html

Obsoletes: RFC 1969

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2419

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets.

RFC 2420 The PPP Triple-DES Encryption Protocol (3DESE)

Authors: H. Kummert.

Date: September 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2420

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
This document provides specific details for the use of the Triple-DES standard (3DES) [6] for encrypting PPP encapsulated packets.

RFC 2421 Voice Profile for Internet Mail - version 2

Authors: G. Vaudreuil, G. Parsons.

Date: September 1998

Formats: txt json html

Obsoletes: RFC 1911

Obsoleted by: RFC 3801

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2421

This document profiles Internet mail for voice messaging. [STANDARDS- TRACK]

RFC 2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration

Authors: G. Vaudreuil, G. Parsons.

Date: September 1998

Formats: txt html json

Obsoletes: RFC 1911

Obsoleted by: RFC 3802

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2422

This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]

RFC 2423 VPIM Voice Message MIME Sub-type Registration

Authors: G. Vaudreuil, G. Parsons.

Date: September 1998

Formats: txt html json

Obsoletes: RFC 1911

Obsoleted by: RFC 3801

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2423

This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK]

RFC 2424 Content Duration MIME Header Definition

Authors: G. Vaudreuil, G. Parsons.

Date: September 1998

Formats: txt json html

Obsoleted by: RFC 3803

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2424

This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]

RFC 2425 A MIME Content-Type for Directory Information

Authors: T. Howes, M. Smith, F. Dawson.

Date: September 1998

Formats: txt json html

Obsoleted by: RFC 6350

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2425

This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]

RFC 2426 vCard MIME Directory Profile

Authors: F. Dawson, T. Howes.

Date: September 1998

Formats: txt html json

Obsoleted by: RFC 6350

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2426

This memo defines the profile of the MIME Content-Type [MIME-DIR] for directory information for a white-pages person object, based on a vCard electronic business card. The profile definition is independent of any particular directory service or protocol. The profile is defined for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). The directory information used by this profile is based on the attributes for the person object defined in the X.520 and X.521 directory services recommendations. The profile also provides the method for including a [VCARD] representation of a white-pages directory entry within the MIME Content-Type defined by the [MIME-DIR] document.

RFC 2427 Multiprotocol Interconnect over Frame Relay

Authors: C. Brown, A. Malis.

Date: September 1998

Formats: txt html json

Obsoletes: RFC 1490, RFC 1294

Also: STD 0055

Status: INTERNET STANDARD

DOI: 10.17487/RFC 2427

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing.
Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use.

RFC 2428 FTP Extensions for IPv6 and NATs

Authors: M. Allman, S. Ostermann, C. Metz.

Date: September 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2428

The specification for the File Transfer Protocol assumes that the underlying network protocol uses a 32-bit network address(specifically IP version 4). With the deployment of version 6 of theInternet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. In addition, the framework defined can support additional network protocols in the future.

RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec

Authors: H.263 Video (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu.

Date: October 1998

Formats: txt json html

Obsoleted by: RFC 4629

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2429

This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK]

RFC 2430 A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)

Authors: T. Li, Y. Rekhter.

Date: October 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2430

This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community.

RFC 2431 RTP Payload Format for BT.656 Video Encoding

Authors: D. Tynan.

Date: October 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2431

This document specifies the RTP payload format for encapsulating ITURecommendation BT.656-3 video streams in the Real-Time TransportProtocol (RTP). Each RTP packet contains all or a portion of one scan line as defined by ITU Recommendation BT.601-5, and includes fragmentation, decoding and positioning information.

RFC 2432 Terminology for IP Multicast Benchmarking

Authors: K. Dubray.

Date: October 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2432

The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 1242, RFC 2285, and other IETF BenchmarkingMethodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.
The BMWG produces two major classes of documents: BenchmarkingTerminology documents and Benchmarking Methodology documents. TheTerminology documents present the benchmarks and other related terms.The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents.

RFC 2433 Microsoft PPP CHAP Extensions

Authors: G. Zorn, S. Cobb.

Date: October 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2433

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This memo provides information for the Internet community.

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 2435 RTP Payload Format for JPEG-compressed Video

Authors: L. Berc, W. Fenner, R. Frederick, S. McCanne, P. Stewart.

Date: October 1998

Formats: txt json html

Obsoletes: RFC 2035

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2435

This memo describes the RTP payload format for JPEG video streams.The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame.
This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem- conf@es.net and/or the author(s).

RFC 2436 Collaboration between ISOC/IETF and ITU-T

Authors: R. Brett, S. Bradner, G. Parsons.

Date: October 1998

Formats: txt html json

Obsoleted by: RFC 3356

Status: INFORMATIONAL

DOI: 10.17487/RFC 2436

This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community.

RFC 2437 PKCS #1: RSA Cryptography Specifications Version 2.0

Authors: B. Kaliski, J. Staddon.

Date: October 1998

Formats: txt html json

Obsoletes: RFC 2313

Obsoleted by: RFC 3447

Status: INFORMATIONAL

DOI: 10.17487/RFC 2437

This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community.

RFC 2438 Advancement of MIB specifications on the IETF Standards Track

Authors: M. O'Dell, H. Alvestrand, B. Wijnen, S. Bradner.

Date: October 1998

Formats: txt json html

Also: BCP 0027

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2438

This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC 2439 BGP Route Flap Damping

Authors: C. Villamizar, R. Chandra, R. Govindan.

Date: November 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2439

A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP.
The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes.
This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead
An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet.This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is"route flap". The techniques described here are now widely deployed and are commonly referred to as "route flap damping".

RFC 2440 OpenPGP Message Format

Authors: J. Callas, L. Donnerhacke, H. Finney, R. Thayer.

Date: November 1998

Formats: txt html json

Obsoleted by: RFC 4880

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2440

This document is maintained in order to publish all necessary information needed to develop interoperable applications based on theOpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network.It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.
Open-PGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used inOpenPGP.

RFC 2441 Working with Jon, Tribute delivered at UCLA, October 30, 1998

Authors: D. Cohen.

Date: November 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2441

This memo provides information for the Internet community.

RFC 2442 The Batch SMTP Media Type

Authors: N. Freed, D. Newman, J. Belissent, M. Hoy.

Date: November 1998

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2442

This document defines a MIME content type suitable for tunneling anESMTP [RFC-821, RFC-1869] transaction through any MIME-capable transport. This type can be used for a variety of purposes, including: Extending end-to-end MIME-based security services (e.g.,[RFC-1847]) to cover message envelope information as well as message content. Making it possible to use specific SMTP extensions such asNOTARY [RFC-1891] over unextended SMTP transport infrastructure.Enabling the transfer of multiple separate messages in a single transactional unit.

RFC 2443 A Distributed MARS Service Using SCSP

Authors: J. Luciani, A. Gallo.

Date: November 1998

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2443

This document describes a method for distributing a MARS service within a LIS[1]. This method uses the Server Cache SynchronizationProtocol (SCSP)[2] to synchronize the MARS Server databases within aLIS. When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG).

RFC 2444 The One-Time-Password SASL Mechanism

Authors: C. Newman.

Date: October 1998

Formats: txt html json

Updates: RFC 2222

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2444

OTP [OTP] provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL [SASL] mechanism so it can be easily and formally integrated into many application protocols.

RFC 2445 Internet Calendaring and Scheduling Core Object Specification (iCalendar)

Authors: F. Dawson, D. Stenerson.

Date: November 1998

Formats: txt html json

Obsoleted by: RFC 5545

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2445

There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across theInternet.
This memo is formatted as a registration for a MIME media type per[RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type.
The proposed media type value is 'text/calendar'. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below.
This MIME media type provides a standard content type for capturing calendar event, to-do and journal entry information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems, using HTTP or some other Internet transport. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities.
This memo is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information.In order to avoid confusion with this referenced work, this memo is to be known as the iCalendar specification.
This memo defines the format for specifying iCalendar object methods.An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do or journal entry calendar component. The iCalendar Transport-indendentInteroperability Protocol (iTIP) defined in [ITIP] is one such scheduling protocol.

RFC 2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries

Authors: S. Silverberg, S. Mansour, F. Dawson, R. Hopson.

Date: November 1998

Formats: txt json html

Obsoleted by: RFC 5546

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2446

This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems.Subsequent documents specify interoperable methods of communications between systems that use this protocol.
The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects.Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects.
This document specifies an Internet protocol based on the iCalendar object specification that provides scheduling interoperability between different calendar systems. The Internet protocol is called the "iCalendar Transport-Independent Interoperability Protocol(iTIP)". iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. iTIP is defined independent of the particular transport used to transmit the scheduling information. Companion memos to iTIP provide bindings of the interoperability protocol to a number of Internet protocols.

RFC 2447 iCalendar Message-Based Interoperability Protocol (iMIP)

Authors: F. Dawson, S. Mansour, S. Silverberg.

Date: November 1998

Formats: txt json html

Obsoleted by: RFC 6047

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2447

This document, [iMIP], specifies a binding from the iCalendarTransport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendarObject Model [iCAL] are composed using constructs from [RFC-822],[RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].
This document is based on discussions within the Internet EngineeringTask Force (IETF) Calendaring and Scheduling (CALSCH) working group.More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents.

RFC 2448 AT&T's Error Resilient Video Transmission Technique

Authors: M. Civanlar, G. Cash, B. Haskell.

Date: November 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2448

This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. The described techniques can be used over packet networks without packet prioritization. These techniques are related to AT&T/Lucent patents[1, 2].

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 2450 Proposed TLA and NLA Assignment Rule

Authors: R. Hinden.

Date: December 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2450

This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID). This memo provides information for the Internet community.

RFC 2451 The ESP CBC-Mode Cipher Algorithms

Authors: R. Pereira, R. Adams.

Date: November 1998

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2451

This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms.

RFC 2452 IP Version 6 Management Information Base for the Transmission Control Protocol

Authors: M. Daniele.

Date: December 1998

Formats: txt json html

Obsoleted by: RFC 4022, RFC 8096

Status: HISTORIC

DOI: 10.17487/RFC 2452

This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the TransmissionControl Protocol (TCP) over IP Version 6 (IPv6).
This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of whichIP versions underlie TCP, and only the TCP connection information isIP version-specific.
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets.

RFC 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 2454 IP Version 6 Management Information Base for the User Datagram Protocol

Authors: M. Daniele.

Date: December 1998

Formats: txt html json

Obsoleted by: RFC 4113, RFC 8096

Status: HISTORIC

DOI: 10.17487/RFC 2454

This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the UserDatagram Protocol (UDP) over IP Version 6 (IPv6).
This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2013 are independent of whichIP versions underlie UDP, and only the UDP listener information is IP version-specific.
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets.

RFC 2455 Definitions of Managed Objects for APPN

Authors: B. Clouston, B. Moore.

Date: November 1998

Formats: txt html json

Obsoletes: RFC 2155

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2455

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol.

RFC 2456 Definitions of Managed Objects for APPN TRAPS

Authors: B. Clouston, B. Moore.

Date: November 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2456

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR(Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture.

RFC 2457 Definitions of Managed Objects for Extended Border Node

Authors: B. Clouston, B. Moore.

Date: November 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2457

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN(Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture.

RFC 2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations

Authors: H. Lu, M. Krishnaswamy, L. Conroy, S. Bellovin, F. Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, K. Vishwanathan.

Date: November 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2458

This document contains the information relevant to the development of the inter-networking interfaces underway in the Public SwitchedTelephone Network (PSTN)/Internet Inter-Networking (PINT) WorkingGroup. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet andPSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over thePSTN. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of thePINT Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of PINT services.

RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile

Authors: R. Housley, W. Ford, W. Polk, D. Solo.

Date: January 1999

Formats: txt html json

Obsoleted by: RFC 3280

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2459

This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms (e.g., IP addresses). Standard certificate extensions are described and one new Internet-specific extension is defined. A required set of certificate extensions is specified. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms(i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are provided in the appendices.

RFC 2460 Internet Protocol, Version 6 (IPv6) Specification

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 2462 IPv6 Stateless Address Autoconfiguration

Authors: S. Thomson, T. Narten.

Date: December 1998

Formats: txt json html

Obsoletes: RFC 1971

Obsoleted by: RFC 4862

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2462

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere.

RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

Authors: A. Conta, S. Deering.

Date: December 1998

Formats: txt json html

Obsoletes: RFC 1885

Obsoleted by: RFC 4443

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2463

This document specifies a set of Internet Control Message Protocol(ICMP) messages for use with version 6 of the Internet Protocol(IPv6).

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 2465 Management Information Base for IP Version 6: Textual Conventions and General Group

Authors: D. Haskin, S. Onishi.

Date: December 1998

Formats: txt html json

Obsoleted by: RFC 4293, RFC 8096

Status: HISTORIC

DOI: 10.17487/RFC 2465

This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document.
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets.
This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions.

RFC 2466 Management Information Base for IP Version 6: ICMPv6 Group

Authors: D. Haskin, S. Onishi.

Date: December 1998

Formats: txt json html

Obsoleted by: RFC 4293, RFC 8096

Status: HISTORIC

DOI: 10.17487/RFC 2466

This document is one in the series of documents that define variousMIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document.
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets.
This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions.

RFC 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 2468 I REMEMBER IANA

Authors: V. Cerf.

Date: October 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2468

A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community.

RFC 2469 A Caution On The Canonical Ordering Of Link-Layer Addresses

Authors: T. Narten, C. Burton.

Date: December 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2469

Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required.

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 2471 IPv6 Testing Address Allocation

Authors: R. Hinden, R. Fink, J. Postel.

Date: December 1998

Formats: txt html json

Obsoletes: RFC 1897

Obsoleted by: RFC 3701

Status: HISTORIC

DOI: 10.17487/RFC 2471

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community.

RFC 2472 IP Version 6 over PPP

Authors: D. Haskin, E. Allen.

Date: December 1998

Formats: txt json html

Obsoletes: RFC 2023

Obsoleted by: RFC 5072, RFC 5172

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2472

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links.

RFC 2473 Generic Packet Tunneling in IPv6 Specification

Authors: A. Conta, S. Deering.

Date: December 1998

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2473

This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others.

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 2476 Message Submission

Authors: R. Gellens, J. Klensin.

Date: December 1998

Formats: txt json html

Obsoleted by: RFC 4409

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2476

This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK]

RFC 2477 Criteria for Evaluating Roaming Protocols

Authors: B. Aboba, G. Zorn.

Date: January 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2477

This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. This memo provides information for the Internet community.

RFC 2478 The Simple and Protected GSS-API Negotiation Mechanism

Authors: E. Baize, D. Pinkas.

Date: December 1998

Formats: txt html json

Obsoleted by: RFC 4178

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2478

This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS- TRACK]

RFC 2479 Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)

Authors: C. Adams.

Date: December 1998

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2479

The IDUP-GSS-API extends the GSS-API for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. This memo provides information for the Internet community.

RFC 2480 Gateways and MIME Security Multiparts

Authors: N. Freed.

Date: January 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2480

This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]

RFC 2481 A Proposal to add Explicit Congestion Notification (ECN) to IP

Authors: K. Ramakrishnan, S. Floyd.

Date: January 1999

Formats: txt html json

Obsoleted by: RFC 3168

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2481

This note describes a proposed addition of ECN (Explicit CongestionNotification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a CongestionExperienced (CE) bit in the packet header of packets from ECN-capable transport protocols. We describe when the CE bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols(e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process.

RFC 2482 Language Tagging in Unicode Plain Text

Authors: K. Whistler, G. Adams.

Date: January 1999

Formats: txt json html

Obsoleted by: RFC 6082

Status: HISTORIC

DOI: 10.17487/RFC 2482

This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community.

RFC 2483 URI Resolution Services Necessary for URN Resolution

Authors: M. Mealling, R. Daniel.

Date: January 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2483

Retrieving the resource identified by a Uniform Resource Identifier(URI) [1] is only one of the operations that can be performed on aURI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to bothUniform Resource Names (URNs) and Uniform Resource Locators (URLs).Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers.
A service in the network providing access to a resource may provide one or some of these options, but it need not provide all of them.This memo specifies an initial set of these operations that can be used to describe the interactions provided by a given access service.It also suggests guidelines that should be adhered to when those operations are encoded in a protocol.

RFC 2484 PPP LCP Internationalization Configuration Option

Authors: G. Zorn.

Date: January 1999

Formats: txt html json

Updates: RFC 2284, RFC 1994, RFC 1570

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2484

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. [STANDARDS-TRACK]

RFC 2485 DHCP Option for The Open Group's User Authentication Protocol

Authors: S. Drach.

Date: January 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2485

This document defines a DHCP [1] option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open GroupNetwork Computing Client Technical Standard [2].

RFC 2486 The Network Access Identifier

Authors: B. Aboba, M. Beadles.

Date: January 1999

Formats: txt json html

Obsoleted by: RFC 4282

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2486

This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK]

RFC 2487 SMTP Service Extension for Secure SMTP over TLS

Authors: P. Hoffman.

Date: January 1999

Formats: txt json html

Obsoleted by: RFC 3207

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2487

This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]

RFC 2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms

Authors: M. Allman, D. Glover, L. Sanchez.

Date: January 1999

Formats: txt html json

Also: BCP 0028

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2488

The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. At this time, all mitigations discussed in this document are IETF standards track mechanisms (or are compliant with IETF standards).

RFC 2489 Procedure for Defining New DHCP Options

Authors: R. Droms.

Date: January 1999

Formats: txt html json

Obsoleted by: RFC 2939

Also: BCP 0029

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2489

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options."
New DHCP options may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters. This document describes the procedure for defining new DHCP options.

RFC 2490 A Simulation Model for IP Multicast with RSVP

Authors: M. Pullen, R. Malghan, L. Lavu, G. Duan, J. Ma, H. Nah.

Date: January 1999

Formats: txt pdf html json ps

Status: INFORMATIONAL

DOI: 10.17487/RFC 2490

This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package [4], with protocol procedures defined in the C language. The model was developed to allow investigation of performance constraints on routing but should have wide applicability in the Internet multicast/resource reservation community. We are making this model publicly available with the intention that it can be used to provide expanded studies of resource-reserved multicasting.

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 2493 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals

Authors: K. Tesink, Ed..

Date: January 1999

Formats: txt json html

Obsoleted by: RFC 3593

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2493

This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals.

RFC 2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type

Authors: D. Fowler, Ed..

Date: January 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2494

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS0 and DS0Bundle interfaces. This document is a companion document withDefinitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495 [17]),DS3/E3 (RFC 2496 [18]), and the work in progress, SONET/SDH InterfaceTypes.
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

RFC 2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types

Authors: D. Fowler, Ed..

Date: January 1999

Formats: txt html json

Obsoletes: RFC 1406

Obsoleted by: RFC 3895

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2495

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document withDefinitions of Managed Objects for the DS0 (RFC 2494 [30]), DS3/E3(RFC 2496 [28]), and the work in progress, SONET/SDH Interface Types.
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

RFC 2496 Definitions of Managed Object for the DS3/E3 Interface Type

Authors: D. Fowler, Ed..

Date: January 1999

Formats: txt json html

Obsoletes: RFC 1407

Obsoleted by: RFC 3896

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2496

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494 [25]), DS1/E1/DS2/E2 (RFC2495 [17]), and the work in progress SONET/SDH Interface Types.
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

RFC 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 2498 IPPM Metrics for Measuring Connectivity

Authors: J. Mahdavi, V. Paxson.

Date: January 1999

Formats: txt html json

Obsoleted by: RFC 2678

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2498

This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community.

RFC 2499 Request for Comments Summary

Authors: A. Ramos.

Date: July 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2499

RFC 2500 Internet Official Protocol Standards

Authors: J. Reynolds, R. Braden.

Date: June 1999

Formats: txt html json

Obsoletes: RFC 2400

Obsoleted by: RFC 2600

Status: HISTORIC

DOI: 10.17487/RFC 2500

This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK]

RFC 2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations

Authors: S. Corson, J. Macker.

Date: January 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2501

This memo first describes the characteristics of Mobile Ad hocNetworks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations.

RFC 2502 Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment

Authors: M. Pullen, M. Myjak, C. Bouwens.

Date: February 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2502

The Large-Scale Multicast Applications (LSMA) working group was chartered to produce documents aimed at a consensus based development of the Internet protocols to support large scale multicast applications including real-time distributed simulation. This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements.

RFC 2503 MIME Types for Use with the ISO ILL Protocol

Authors: R. Moulton, M. Needleman.

Date: February 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2503

This memorandum describes a set of MIME types for use with the ISOInterlibrary Loan Protocol (ISO 10160/10161). Two MIME types are specified below.
The first is a media type to carry objects which are BER [BER] encoded ISO ILL Protocol Data Units (PDU's). BER are the basicEncoding Rules used to encode PDU's which have been described usingASN.1 (Abstract Syntax Notation 1) [ASN.1] .
The second is for use with the associated document delivery instructions. Document Delivery Instructions (DDI) is an emerging protocol which enables automatic electronic delivery of items. It allows a request management system (which might have received a request for an item via the ISO Interlibrary Loan Protocol (ISO10160/10161)) to pass details of the request, item, and delivery, to a delivery module, and to receive back reports on the delivery process or arrival of an item. It is currently being submitted to theISO TC46/SC4/WG4 committee for approval as an ISO standard.

RFC 2504 Users' Security Handbook

Authors: E. Guttman, L. Leong, G. Malkin.

Date: February 1999

Formats: txt html json

Also: FYI 0034

Status: INFORMATIONAL

DOI: 10.17487/RFC 2504

The Users' Security Handbook is the companion to the Site SecurityHandbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure.

RFC 2505 Anti-Spam Recommendations for SMTP MTAs

Authors: G. Lindberg.

Date: February 1999

Formats: txt html json

Also: BCP 0030

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2505

This memo gives a number of implementation recommendations for SMTP,[1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) to make them more capable of reducing the impact of spam(*).
The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature.
The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to.For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack.
A brief summary of this memo is: o Stop unauthorized mail relaying. o Spammers then have to operate in the open; deal with them. o Design a mail system that can handle spam.

RFC 2506 Media Feature Tag Registration Procedure

Authors: K. Holtman, A. Mutz, T. Hardie.

Date: March 1999

Formats: txt json html

Also: BCP 0031

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2506

This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC 2507 IP Header Compression

Authors: M. Degermark, B. Nordgren, S. Pink.

Date: February 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2507

This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP andUDP headers, and encapsulated IPv6 and IPv4 headers.
Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low and medium speed links.
The compression algorithms are specifically designed to work well over links with nontrivial packet-loss rates. Several wireless and modem technologies result in such links.

RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links

Authors: S. Casner, V. Jacobson.

Date: February 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2508

This document describes a method for compressing the headers ofIP/UDP/RTP datagrams to reduce overhead on low-speed serial links.In many cases, all three headers can be compressed to 2-4 bytes.
Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s).

RFC 2509 IP Header Compression over PPP

Authors: M. Engan, S. Casner, C. Bormann.

Date: February 1999

Formats: txt html json

Obsoleted by: RFC 3544

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2509

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-PointProtocol [RFC1661]. It defines extensions to the PPP ControlProtocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP,UDP and RTP transport protocols as specified in [IPHC] and [CRTP].

RFC 2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols

Authors: C. Adams, S. Farrell.

Date: March 1999

Formats: txt html json

Obsoleted by: RFC 4210

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2510

This document describes the Internet X.509 Public Key Infrastructure(PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management.Note that "certificate" in this document refers to an X.509v3Certificate as defined in [COR95, X509-AM].

RFC 2511 Internet X.509 Certificate Request Message Format

Authors: M. Myers, C. Adams, D. Solo, D. Kemp.

Date: March 1999

Formats: txt html json

Obsoleted by: RFC 4211

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2511

This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]

RFC 2512 Accounting Information for ATM Networks

Authors: K. McCloghrie, J. Heinanen, W. Greene, A. Prasad.

Date: February 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2512

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK]

RFC 2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks

Authors: K. McCloghrie, J. Heinanen, W. Greene, A. Prasad.

Date: February 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2513

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 controlling the collection and storage of accounting information for connection-oriented networks such as ATM. [STANDARDS-TRACK]

RFC 2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management

Authors: M. Noto, E. Spiegel, K. Tesink.

Date: February 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2514

This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services.

RFC 2515 Definitions of Managed Objects for ATM Management

Authors: K. Tesink, Ed..

Date: February 1999

Formats: txt html json

Obsoletes: RFC 1695

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2515

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE)

Authors: L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler.

Date: February 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2516

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet.

RFC 2517 Building Directories from DNS: Experiences from WWWSeeker

Authors: R. Moats, R. Huber.

Date: February 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2517

There has been much discussion and several documents written about the need for an Internet Directory. Recently, this discussion has focused on ways to discover an organization's domain name without relying on use of DNS as a directory service. This memo discusses lessons that were learned during InterNIC Directory and DatabaseServices' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. The back end database that drives this application was built from information obtained from domain registries via WHOIS and other protocols. We present this information to help future implementors avoid some of the blind alleys that we have already explored. This work builds on the Netfind system that was created byMike Schwartz and his team at the University of Colorado at Boulder[1].

RFC 2518 HTTP Extensions for Distributed Authoring -- WEBDAV

Authors: Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen.

Date: February 1999

Formats: txt html json

Obsoleted by: RFC 4918

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2518

This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance).

RFC 2519 A Framework for Inter-Domain Route Aggregation

Authors: E. Chen, J. Stewart.

Date: February 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2519

This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the 'no-export' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing.

RFC 2520 NHRP with Mobile NHCs

Authors: J. Luciani, H. Suzuki, N. Doraswamy, D. Horton.

Date: February 1999

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2520

This document describes an extension to NHRP [1] which would allowMobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner.
As described in this document, Mobile NHCs are NHCs which are not configured with enough information to find a specific serving NHS in their home LIS, but which have a mechanism to find an NHS (which may or may not be a serving NHS) to which they will attach. As described in [1], an NHC may attach to a 'surrogate' NHS by using a mechanism such as an anycast address. In this case, the NHC may use the surrogate NHS to send a NHRP Registration Request toward the NHC's home LIS where a serving NHS resides. However, as defined in [1], packet authentication is performed on a hop by hop basis. In the mobile NHC case, it is not practical for the mobile NHC be in a security relationship with every surrogate NHS, thus it is presumably desirable to have some form of end to end only authentication for the case of a mobile NHC's registration. This document describes an authentication extension for NHRP which has such end to end only semantics.

RFC 2521 ICMP Security Failures Messages

Authors: P. Karn, W. Simpson.

Date: March 1999

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2521

This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP).

RFC 2522 Photuris: Session-Key Management Protocol

Authors: P. Karn, W. Simpson.

Date: March 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2522

Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms.

RFC 2523 Photuris: Extended Schemes and Attributes

Authors: P. Karn, W. Simpson.

Date: March 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2523

Photuris is a session-key management protocol. Extensible Exchange-Schemes are provided to enable future implementation changes without affecting the basic protocol.
Additional authentication attributes are included for use with the IPAuthentication Header (AH) or the IP Encapsulating Security Protocol(ESP).
Additional confidentiality attributes are included for use with ESP.

RFC 2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3

Authors: M. Banan.

Date: February 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2524

This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. This memo provides information for the Internet community.

RFC 2525 Known TCP Implementation Problems

Authors: V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B. Volz.

Date: March 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2525

This memo catalogs a number of known TCP implementation problems. This memo provides information for the Internet community.

RFC 2526 Reserved IPv6 Subnet Anycast Addresses

Authors: D. Johnson, S. Deering.

Date: March 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2526

The IP Version 6 addressing architecture defines an "anycast" address as an IPv6 address that is assigned to one or more network interfaces(typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses.

RFC 2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework

Authors: S. Chokhani, W. Ford.

Date: March 1999

Formats: txt json html

Obsoleted by: RFC 3647

Status: INFORMATIONAL

DOI: 10.17487/RFC 2527

This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement.

RFC 2528 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates

Authors: R. Housley, W. Polk.

Date: March 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2528

The Key Exchange Algorithm (KEA) is a classified algorithm for exchanging keys. This specification profiles the format and semantics of fields in X.509 V3 certificates containing KEA keys. The specification addresses the subjectPublicKeyInfo field and the keyUsage extension.

RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels

Authors: B. Carpenter, C. Jung.

Date: March 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2529

This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, RouterAdvertisement, Neighbor Solicitation, and Neighbor Advertisement andRedirect messages, when those messages are transmitted on an IPv4 multicast network.
The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It usesIPv4 multicast as a "virtual Ethernet".

RFC 2530 Indicating Supported Media Features Using Extensions to DSN and MDN

Authors: D. Wing.

Date: March 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2530

This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK]

RFC 2531 Content Feature Schema for Internet Fax

Authors: G. Klyne, L. McIntyre.

Date: March 1999

Formats: txt html json

Obsoleted by: RFC 2879

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2531

This document defines a content feature schema that is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extended Internet fax systems [5].
This document does not describe any specific mechanisms for communicating capability information, but does presume that any such mechanisms will transfer textual values. It specifies a textual format to be used for describing Internet fax capability information.

RFC 2532 Extended Facsimile Using Internet Mail

Authors: L. Masinter, D. Wing.

Date: March 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2532

This document describes extensions to "Simple Mode of Facsimile UsingInternet Mail" [RFC2305] and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing.
These additional features are designed to provide the highest level of interoperability with the existing and future standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates the level currently enjoyed by fax users.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in <http://www.ietf.org/ipr.html&rt;.

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 2534 Media Features for Display, Print, and Fax

Authors: L. Masinter, D. Wing, A. Mutz, K. Holtman.

Date: March 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2534

This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications.These features are registered for use within the framework of [REG].

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 2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)

Authors: D. Eastlake 3rd.

Date: March 1999

Formats: txt json html

Obsoleted by: RFC 3110

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2537

A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNSKEY and SIG resource records.

RFC 2538 Storing Certificates in the Domain Name System (DNS)

Authors: D. Eastlake 3rd, O. Gudmundsson.

Date: March 1999

Formats: txt html json

Obsoleted by: RFC 4398

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2538

Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record(RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS).

RFC 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 2540 Detached Domain Name System (DNS) Information

Authors: D. Eastlake 3rd.

Date: March 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2540

A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet.

RFC 2541 DNS Security Operational Considerations

Authors: D. Eastlake 3rd.

Date: March 1999

Formats: txt json html

Obsoleted by: RFC 4641

Status: INFORMATIONAL

DOI: 10.17487/RFC 2541

Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records.

RFC 2542 Terminology and Goals for Internet Fax

Authors: L. Masinter.

Date: March 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2542

This document defines a number of terms useful for the discussion ofInternet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. It encompasses the goals for all modes of facsimile delivery, including'real-time', 'session', and 'store and forward'. Different levels of desirability are indicated throughout the document.

RFC 2543 SIP: Session Initiation Protocol

Authors: M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg.

Date: March 1999

Formats: txt html json

Obsoleted by: RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2543

The Session Initiation Protocol (SIP) is an application-layer control(signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types.SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.

RFC 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 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing

Authors: P. Marques, F. Dupont.

Date: March 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2545

BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information.This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information.

RFC 2546 6Bone Routing Practice

Authors: A. Durand, B. Buclin.

Date: March 1999

Formats: txt html json

Obsoleted by: RFC 2772

Status: INFORMATIONAL

DOI: 10.17487/RFC 2546

This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community.

RFC 2547 BGP/MPLS VPNs

Authors: E. Rosen, Y. Rekhter.

Date: March 1999

Formats: txt html json

Obsoleted by: RFC 4364

Status: INFORMATIONAL

DOI: 10.17487/RFC 2547

This document describes a method by which a Service Provider with anIP backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border GatewayProtocol) is used for distributing routes over the backbone. The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. These techniques can also be used to provide a VPN which itself provides IP service to customers.

RFC 2548 Microsoft Vendor-specific RADIUS Attributes

Authors: G. Zorn.

Date: March 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2548

This document describes the set of Microsoft vendor-specific RADIUS attributes. These attributes are designed to support Microsoft proprietary dial-up protocols and/or provide support for features which is not provided by the standard RADIUS attribute set [3]. It is expected that this memo will be updated whenever Microsoft defines a new vendor-specific attribute, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products.

RFC 2549 IP over Avian Carriers with Quality of Service

Authors: D. Waitzman.

Date: 1 April 1999

Formats: txt json html

Updates: RFC 1149

Status: INFORMATIONAL

DOI: 10.17487/RFC 2549

This memo amends RFC 1149, "A Standard for the Transmission of IPDatagrams on Avian Carriers", with Quality of Service information.This is an experimental, not recommended standard.

RFC 2550 Y10K and Beyond

Authors: S. Glassman, M. Manasse, J. Mogul.

Date: 1 April 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2550

As we approach the end of the millennium, much attention has been paid to the so-called "Y2K" problem. Nearly everyone now regrets the short-sightedness of the programmers of yore who wrote programs designed to fail in the year 2000. Unfortunately, the current fixes for Y2K lead inevitably to a crisis in the year 10,000 when the programs are again designed to fail.
This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem(Roman numerals).

RFC 2551 The Roman Standards Process -- Revision III

Authors: S. Bradner.

Date: 1 April 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2551

This memo documents the process used by the Roman 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 2552 Architecture for the Information Brokerage in the ACTS Project GAIA

Authors: M. Blinov, M. Bessonov, C. Clissmann.

Date: April 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2552

This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability).

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 2554 SMTP Service Extension for Authentication

Authors: J. Myers.

Date: March 1999

Formats: txt json html

Obsoleted by: RFC 4954

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2554

This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK]

RFC 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 2556 OSI connectionless transport services on top of UDP Applicability Statement for Historic Status

Authors: S. Bradner.

Date: March 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2556

RFC 1240, "OSI connectionless transport services on top of UDP", was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility.

RFC 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)

Authors: J. Palme, A. Hopmann, N. Shelness.

Date: March 1999

Formats: txt html json

Obsoletes: RFC 2110

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2557

HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object) and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers(URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI.
In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by whichURIs in the text/html root can reference subsidiary resources within that composite message structure.
This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header(Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure.
While initially designed to support e-mail transfer of complete multi-resource HTML multimedia documents, these conventions can also be employed to resources retrieved by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents.
Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 12.

RFC 2558 Definitions of Managed Objects for the SONET/SDH Interface Type

Authors: K. Tesink.

Date: March 1999

Formats: txt json html

Obsoletes: RFC 1595

Obsoleted by: RFC 3592

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2558

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK]

RFC 2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2

Authors: S. Boeyen, T. Howes, P. Richard.

Date: April 1999

Formats: txt json html

Obsoleted by: RFC 3494

Updates: RFC 1778

Status: HISTORIC

DOI: 10.17487/RFC 2559

Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK]

RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP

Authors: M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 6960

Updated by: RFC 6277

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2560

This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS- TRACK]

RFC 2561 Base Definitions of Managed Objects for TN3270E Using SMIv2

Authors: K. White, R. Moore.

Date: April 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2561

This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices.
The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. A TN3270E server connects a Telnet client performing 3270 emulation to a target SNA host over both a client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host). The client-side network is typically TCP/IP, but it need not be.
A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA)System Services Control Point (SSCP) for the dependent SecondaryLogical Units (SLUs) that the server makes available to its clients for connecting into a SNA network. A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR). Host and gatewayTN3270E server implementations typically differ greatly as to their internal implementation and system definition (SYSDEF) methods.
It is the intent that the MIB defined herein be extended by subsequent memos. For example, one such extension enables collection of TN3270E response time data.

RFC 2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)

Authors: K. White, R. Moore.

Date: April 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2562

This memo defines the protocol and the Management Information Base(MIB) for performing response time data collection on TN3270 andTN3270E sessions by a TN3270E server. The response time data collected by a TN3270E server is structured to support both validation of service level agreements and performance monitoring ofTN3270 and TN3270E Sessions. This MIB has as a prerequisite theTN3270E-MIB, reference [20].
TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices.

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 2564 Application Management MIB

Authors: C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia.

Date: May 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2564

This memo defines a standards track portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. This MIB complements the SystemApplication MIB, providing for the management of applications' common attributes which could not typically be observed without the cooperation of the software being managed.

RFC 2565 Internet Printing Protocol/1.0: Encoding and Transport

Authors: R. Herriot, Ed., S. Butler, P. Moore, R. Turner.

Date: April 1999

Formats: txt json html

Obsoleted by: RFC 2910

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2565

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a newInternet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp".
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport (this document)Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport.It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
The document "Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.

RFC 2566 Internet Printing Protocol/1.0: Model and Semantics

Authors: R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell.

Date: April 1999

Formats: txt html json

Obsoleted by: RFC 2911

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2566

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport.The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs.This document also addresses security, internationalization, and directory issues.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics (this document)Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.

RFC 2567 Design Goals for an Internet Printing Protocol

Authors: F. Wright.

Date: April 1999

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2567

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 takes a broad look at distributed printing functionality, and it enumerates real- life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol (this document)Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2568]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The "Internet Printing Protocol/1.0: Model and Semantics" 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. TheJob optionally supports multiple documents. IPP 1.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs. This document also addresses security, internationalization, and directory issues.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.

RFC 2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol

Authors: S. Zilles.

Date: April 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2568

This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. This memo defines an Experimental Protocol for the Internet community.

RFC 2569 Mapping between LPD and IPP Protocols

Authors: R. Herriot, Ed., T. Hastings, N. Jacobs, J. Martin.

Date: April 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2569

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 gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon). This document describes the mapping between (1) the commands and operands of the 'Line Printer Daemon (LPD) Protocol' specified inRFC 1179 and (2) the operations, operation attributes and job template attributes of the Internet Printing Protocol/1.0 (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP.
WARNING: RFC 1179 was not on the IETF standards track. While RFC1179 was intended to record existing practice, it fell short in some areas. However, this specification maps between (1) the actual current practice of RFC 1179 and (2) IPP. This document does not attempt to map the numerous divergent extensions to the LPD protocol that have been made by many implementers.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementors Guide [ipp-iig]Mapping between LPD and IPP Protocols (this document)
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. It introduces a Printer and a Job object. TheJob object supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called ' application/ipp'.
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.

RFC 2570 Introduction to Version 3 of the Internet-standard Network Management Framework

Authors: J. Case, R. Mundy, D. Partain, B. Stewart.

Date: April 1999

Formats: txt json html

Obsoleted by: RFC 3410

Status: INFORMATIONAL

DOI: 10.17487/RFC 2570

The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed theSNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-standard ManagementFramework (SNMPv1) and the second Internet-standard ManagementFramework (SNMPv2).
The architecture is designed to be modular to allow the evolution of the Framework over time.

RFC 2571 An Architecture for Describing SNMP Management Frameworks

Authors: B. Wijnen, D. Harrington, R. Presuhn.

Date: April 1999

Formats: txt json html

Obsoletes: RFC 2271

Obsoleted by: RFC 3411

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2571

This document describes an architecture for describing SNMPManagement Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data.

RFC 2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

Authors: J. Case, D. Harrington, R. Presuhn, B. Wijnen.

Date: April 1999

Formats: txt html json

Obsoletes: RFC 2272

Obsoleted by: RFC 3412

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2572

This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2571]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.

RFC 2573 SNMP Applications

Authors: D. Levi, P. Meyer, B. Stewart.

Date: April 1999

Formats: txt html json

Obsoletes: RFC 2273

Obsoleted by: RFC 3413

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2573

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2571]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding.

RFC 2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)

Authors: U. Blumenthal, B. Wijnen.

Date: April 1999

Formats: txt json html

Obsoletes: RFC 2274

Obsoleted by: RFC 3414

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2574

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2571]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model.

RFC 2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

Authors: B. Wijnen, R. Presuhn, K. McCloghrie.

Date: April 1999

Formats: txt json html

Obsoletes: RFC 2275

Obsoleted by: RFC 3415

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2575

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2571]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model.

RFC 2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

Authors: R. Frye, D. Levi, S. Routhier, B. Wijnen.

Date: March 2000

Formats: txt html json

Obsoletes: RFC 1908, RFC 2089

Obsoleted by: RFC 3584

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2576

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework,(SNMPv3), version 2 of the Internet-standard Network ManagementFramework (SNMPv2), and the original Internet-standard NetworkManagement Framework (SNMPv1). This document obsoletes RFC 1908 [13] and RFC2089 [14].

RFC 2577 FTP Security Considerations

Authors: M. Allman, S. Ostermann.

Date: May 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2577

The specification for the File Transfer Protocol (FTP) contains a number of mechanisms that can be used to compromise network security.The FTP specification allows a client to instruct a server to transfer files to a third machine. This third-party mechanism, known as proxy FTP, causes a well known security problem. The FTP specification also allows an unlimited number of attempts at entering a user's password. This allows brute force "password guessing" attacks. This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP.

RFC 2578 Structure of Management Information Version 2 (SMIv2)

Authors: K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed..

Date: April 1999

Formats: txt json html

Obsoletes: RFC 1902

Also: STD 0058

Status: INTERNET STANDARD

DOI: 10.17487/RFC 2578

It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]

RFC 2579 Textual Conventions for SMIv2

Authors: K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed..

Date: April 1999

Formats: txt json html

Obsoletes: RFC 1903

Also: STD 0058

Status: INTERNET STANDARD

DOI: 10.17487/RFC 2579

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

RFC 2580 Conformance Statements for SMIv2

Authors: K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed..

Date: April 1999

Formats: txt json html

Obsoletes: RFC 1904

Also: STD 0058

Status: INTERNET STANDARD

DOI: 10.17487/RFC 2580

Collections of related objects are defined in MIB modules. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

RFC 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 2582 The NewReno Modification to TCP's Fast Recovery Algorithm

Authors: S. Floyd, T. Henderson.

Date: April 1999

Formats: txt html json

Obsoleted by: RFC 3782

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2582

RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, FastRetransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to asNewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95].

RFC 2583 Guidelines for Next Hop Client (NHC) Developers

Authors: R. Carlson, L. Winkler.

Date: May 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2583

This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. This memo provides information for the Internet community.

RFC 2584 Definitions of Managed Objects for APPN/HPR in IP Networks

Authors: B. Clouston, B. Moore.

Date: May 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2584

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for monitoring and controlling HPR(High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. This memo identifies managed objects for the HPR in IP network communications.

RFC 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP

Authors: R. Housley, P. Hoffman.

Date: May 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2585

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 File Transfer Protocol (FTP) and the Hypertext TransferProtocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressingPKIX operational requirements are specified in separate documents.

RFC 2586 The Audio/L16 MIME content type

Authors: J. Salsman, H. Alvestrand.

Date: May 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2586

This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. This memo provides information for the Internet community.

RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema

Authors: S. Boeyen, T. Howes, P. Richard.

Date: June 1999

Formats: txt html json

Obsoleted by: RFC 4523

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2587

The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK]

RFC 2588 IP Multicast and Firewalls

Authors: R. Finlayson.

Date: May 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2588

In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. This memo provides information for the Internet community.

RFC 2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services

Authors: Y. Yaacovi, M. Wahl, T. Genovese.

Date: May 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2589

This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. [STANDARDS-TRACK]

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 2591 Definitions of Managed Objects for Scheduling Management Operations

Authors: D. Levi, J. Schoenwaelder.

Date: May 1999

Formats: txt json html

Obsoleted by: RFC 3231

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2591

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times.

RFC 2592 Definitions of Managed Objects for the Delegation of Management Script

Authors: D. Levi, J. Schoenwaelder.

Date: May 1999

Formats: txt html json

Obsoleted by: RFC 3165

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2592

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers.

RFC 2593 Script MIB Extensibility Protocol Version 1.0

Authors: J. Schoenwaelder, J. Quittek.

Date: May 1999

Formats: txt html json

Obsoleted by: RFC 3179

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2593

The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. A management script is a set of instructions that are executed by a language specific runtime system. The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations.

RFC 2594 Definitions of Managed Objects for WWW Services

Authors: H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder.

Date: May 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2594

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community.In particular it describes a set of objects for managing World WideWeb (WWW) services.

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 2596 Use of Language Codes in LDAP

Authors: M. Wahl, T. Howes.

Date: May 1999

Formats: txt html json

Obsoleted by: RFC 3866

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2596

This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [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 2598 An Expedited Forwarding PHB

Authors: V. Jacobson, K. Nichols, K. Poduri.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 3246

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2598

The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. We show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a Virtual Leased Line. A recommended codepoint for this PHB is given.
A pdf version of this document is available at ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf

RFC 2599 Request for Comments Summary RFC Numbers 2500-2599

Authors: A. DeLaCruz.

Date: March 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2599

RFC 2600 Internet Official Protocol Standards

Authors: J. Reynolds, R. Braden.

Date: March 2000

Formats: txt json html

Obsoletes: RFC 2500

Obsoleted by: RFC 2700

Status: HISTORIC

DOI: 10.17487/RFC 2600

This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK]

RFC 2601 ILMI-Based Server Discovery for ATMARP

Authors: M. Davison.

Date: June 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2601

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers.

RFC 2602 ILMI-Based Server Discovery for MARS

Authors: M. Davison.

Date: June 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2602

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers.

RFC 2603 ILMI-Based Server Discovery for NHRP

Authors: M. Davison.

Date: June 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2603

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers.

RFC 2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP

Authors: R. Gellens.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 2636

Status: INFORMATIONAL

DOI: 10.17487/RFC 2604

Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol.

RFC 2605 Directory Server Monitoring MIB

Authors: G. Mansfield, S. Kille.

Date: June 1999

Formats: txt json html

Obsoletes: RFC 1567

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2605

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1567, "X.500 Directory Monitoring MIB". This memo extends that specification to a more generic MIB for monitoring one or more directory servers each of which may support multiple access protocols. The MIB defined in this memo will be used in conjunction with the NETWORK-SERVICES-MIB [19] for monitoringDirectory Servers.

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 2607 Proxy Chaining and Policy Implementation in Roaming

Authors: B. Aboba, J. Vollbrecht.

Date: June 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2607

This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community.

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 2609 Service Templates and Service: Schemes

Authors: E. Guttman, C. Perkins, J. Kempf.

Date: June 1999

Formats: txt json html

Updates: RFC 2165

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2609

The "service:" URL scheme name is used to define URLs (called"service: URLs" in this document) that are primarily intended to be used by the Service Location Protocol in order to distribute service access information. These schemes provide an extensible framework for client-based network software to obtain configuration information required to make use of network services. When registering a service: URL, the URL is accompanied by a set of well-defined attributes which define the service. These attributes convey configuration information to client software, or service characteristics meaningful to end users.
This document describes a formal procedure for defining and standardizing new service types and attributes for use with the"service:" scheme. The formal descriptions of service types and attributes are templates that are human and machine understandable.They SHOULD be used by administrative tools to parse service registration information and by client applications to provide localized translations of service attribute strings.

RFC 2610 DHCP Options for Service Location Protocol

Authors: C. Perkins, E. Guttman.

Date: June 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2610

The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network.Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents.

RFC 2611 URN Namespace Definition Mechanisms

Authors: L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 3406

Also: BCP 0033

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2611

The URN WG has defined a syntax for Uniform Resource Names (URNs)[RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFC2168, RFC2169]). The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN "namespaces".

RFC 2612 The CAST-256 Encryption Algorithm

Authors: C. Adams, J. Gilchrist.

Date: June 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2612

There is always a desire in the Internet community for unencumbered encryption algorithms with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.
This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A).

RFC 2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0

Authors: R. Waterman, B. Lahaye, D. Romascanu, S. Waldbusser.

Date: June 1999

Formats: txt html json

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2613

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 in switched networks environments.

RFC 2614 An API for Service Location

Authors: J. Kempf, E. Guttman.

Date: June 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2614

The Service Location Protocol (SLP) provides a new way for clients to dynamically discovery network services. With SLP, it is simple to offer highly available services that require no user configuration or assistance from network administrators prior to use. This document describes standardized APIs for SLP in C and Java. The APIs are modular and are designed to allow implementations to offer just the feature set needed. In addition, standardized file formats for configuration and serialized registrations are defined, allowing SLP agents to set network and other parameters in a portable way. The serialized file format allows legacy services to be registered withSLP directory agents in cases where modifying the legacy service program code is difficult or impossible, and to portably exchange a registration database.

RFC 2615 PPP over SONET/SDH

Authors: A. Malis, W. Simpson.

Date: June 1999

Formats: txt json html

Obsoletes: RFC 1619

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2615

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Synchronous OpticalNetwork (SONET) and Synchronous Digital Hierarchy (SDH) circuits.
This document replaces and obsoletes RFC 1619. See section 7 for a summary of the changes from RFC 1619.

RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1

Authors: R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee.

Date: June 1999

Formats: txt ps html pdf json

Obsoletes: RFC 2068

Obsoleted by: RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235

Updated by: RFC 2817, RFC 5785, RFC 6266, RFC 6585

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2616

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33].

RFC 2617 HTTP Authentication: Basic and Digest Access Authentication

Authors: J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart.

Date: June 1999

Formats: txt html json

Obsoletes: RFC 2069

Obsoleted by: RFC 7235, RFC 7615, RFC 7616, RFC 7617

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2617

"HTTP/1.0", includes the specification for a Basic AccessAuthentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext.
This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "DigestAccess Authentication". It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified byRFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended.
Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.

RFC 2618 RADIUS Authentication Client MIB

Authors: B. Aboba, G. Zorn.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 4668

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2618

This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients.

RFC 2619 RADIUS Authentication Server MIB

Authors: G. Zorn, B. Aboba.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 4669

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2619

This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers.

RFC 2620 RADIUS Accounting Client MIB

Authors: B. Aboba, G. Zorn.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 4670

Status: INFORMATIONAL

DOI: 10.17487/RFC 2620

This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients.

RFC 2621 RADIUS Accounting Server MIB

Authors: G. Zorn, B. Aboba.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 4671

Status: INFORMATIONAL

DOI: 10.17487/RFC 2621

This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers.

RFC 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 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5

Authors: M. Eisler.

Date: June 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2623

This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how theVersion 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. This memorandum is provided so that people can write compatible implementations.

RFC 2624 NFS Version 4 Design Considerations

Authors: S. Shepler.

Date: June 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2624

The main task of the NFS version 4 working group is to create a protocol definition for a distributed file system that focuses on the following items: improved access and good performance on theInternet, strong security with negotiation built into the protocol, better cross-platform interoperability, and designed for protocol extensions. NFS version 4 will owe its general design to the previous versions of NFS. It is expected, however, that many features will be quite different in NFS version 4 than previous versions to facilitate the goals of the working group and to address areas that NFS version 2 and 3 have not.
This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. Based on this investigation the working group will decide the features of the new protocol based on the cost and benefits within the specific feature areas.

RFC 2625 IP and ARP over Fibre Channel

Authors: M. Rajagopal, R. Bhagwat, W. Rickard.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 4338

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2625

Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small ComputerSystem Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards[3] do not adequately specify how IP packets may be transported overFC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and AddressResolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution.

RFC 2626 The Internet and the Millennium Problem (Year 2000)

Authors: P. Nesser II.

Date: June 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2626

The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols.This investigation only targeted the protocols as documented in theRequest For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost allInternet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation.

RFC 2627 Key Management for Multicast: Issues and Architectures

Authors: D. Wallner, E. Harder, R. Agee.

Date: June 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2627

This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals [1,2,4]. The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group.

RFC 2628 Simple Cryptographic Program Interface (Crypto API)

Authors: V. Smyslov.

Date: June 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2628

This document describes a simple Application Program Interface to cryptographic functions. The main purpose of such an interface is to separate cryptographic libraries from internet applications, thus allowing an independent development of both. It can be used in various internet applications such as [IPsec], [ISAKMP], [IKE],[TLS].

RFC 2629 Writing I-Ds and RFCs using XML

Authors: M. Rose.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 7749

Status: INFORMATIONAL

DOI: 10.17487/RFC 2629

This memo presents a technique for using XML (Extensible MarkupLanguage) as a source format for documents in the Internet-Drafts(I-Ds) and Request for Comments (RFC) series.

RFC 2630 Cryptographic Message Syntax

Authors: R. Housley.

Date: June 1999

Formats: txt json html

Obsoleted by: RFC 3369, RFC 3370

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2630

This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.
The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate attribute certificate transfer and key agreement techniques for key management.

RFC 2631 Diffie-Hellman Key Agreement Method

Authors: E. Rescorla.

Date: June 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2631

This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary amount of keying material is provided. The resulting keying material is used as a symmetric encryption key. The Diffie-Hellman variant described requires the recipient to have a certificate, but the originator may have a static key pair (with the public key placed in a certificate) or an ephemeral key pair.

RFC 2632 S/MIME Version 3 Certificate Handling

Authors: B. Ramsdell, Ed..

Date: June 1999

Formats: txt html json

Obsoleted by: RFC 3850

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2632

S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK]

RFC 2633 S/MIME Version 3 Message Specification

Authors: B. Ramsdell, Ed..

Date: June 1999

Formats: txt html json

Obsoleted by: RFC 3851

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2633

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]

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 2635 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*)

Authors: S. Hambridge, A. Lunde.

Date: June 1999

Formats: txt json html

Also: FYI 0035

Status: INFORMATIONAL

DOI: 10.17487/RFC 2635

This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. It gives a set of guidelines for dealing with unsolicited mail for users, for system administrators, news administrators, and mailing list managers. It also makes suggestions Internet Service Providers might follow.

RFC 2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP

Authors: R. Gellens.

Date: July 1999

Formats: txt html ps json pdf

Obsoletes: RFC 2604

Status: INFORMATIONAL

DOI: 10.17487/RFC 2636

Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol.

RFC 2637 Point-to-Point Tunneling Protocol (PPTP)

Authors: K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn.

Date: July 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2637

This document specifies a protocol which allows the Point to PointProtocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network AccessServers (NAS) and support Virtual Private Networks (VPNs). The PPTPNetwork Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP AccessConcentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit- switched connections. PPTP uses an enhanced GRE (Generic RoutingEncapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets.

RFC 2638 A Two-bit Differentiated Services Architecture for the Internet

Authors: K. Nichols, V. Jacobson, L. Zhang.

Date: July 1999

Formats: txt ps json html pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 2638

This document was originally submitted as an internet draft inNovember of 1997. As one of the documents predating the formation of the IETF's Differentiated Services Working Group, many of the ideas presented here, in concert with Dave Clark's subsequent presentation to the December 1997 meeting of the IETF Integrated Services WorkingGroup, were key to the work which led to RFCs 2474 and 2475 and the section on allocation remains a timely proposal. For this reason, and to provide a reference, it is being submitted in its original form.The forwarding path portion of this document is intended as a record of where we were at in late 1997 and not as an indication of future direction.
The postscript version of this document includes Clark's slides as an appendix. The postscript version of this document also includes many figures that aid greatly in its readability.

RFC 2639 Internet Printing Protocol/1.0: Implementer's Guide

Authors: T. Hastings, C. Manros.

Date: July 1999

Formats: txt json html

Obsoleted by: RFC 3196

Status: INFORMATIONAL

DOI: 10.17487/RFC 2639

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. TheJob supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It also defines the encoding rules for a new Internet media type called"application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.

RFC 2640 Internationalization of the File Transfer Protocol

Authors: B. Curtin.

Date: July 1999

Formats: txt html json

Updates: RFC 0959

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2640

The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC1123 Section 4 [RFC1123], is one of the oldest and widely used protocols on the Internet. The protocol's primary character set, 7 bit ASCII, has served the protocol well through the early growth years of the Internet. However, as the Internet becomes more global, there is a need to support character sets beyond 7 bit ASCII.
This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending theFTP specification and giving recommendations for proper internationalization support.

RFC 2641 Cabletron's VlanHello Protocol Specification Version 4

Authors: D. Hamilton, D. Ruffen.

Date: August 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2641

The VlanHello protocol is part of the InterSwitch Message Protocol(ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric.

RFC 2642 Cabletron's VLS Protocol Specification

Authors: L. Kane.

Date: August 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2642

The Virtual LAN Link State Protocol (VLSP) is part of the InterSwitchMessage Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. VLSP is used to determine and maintain a fully connected mesh topology graph of the switch fabric. Each switch maintains an identical database describing the topology. Call-originating switches use the topology database to determine the path over which to route a call connection.
VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic.

RFC 2643 Cabletron's SecureFast VLAN Operational Model

Authors: D. Ruffen, T. Len, J. Yanacek.

Date: August 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2643

Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages.

RFC 2644 Changing the Default for Directed Broadcasts in Routers

Authors: D. Senie.

Date: August 1999

Formats: txt html json

Updates: RFC 1812

Also: BCP 0034

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2644

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. This memo provides information for the Internet community.

RFC 2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses

Authors: R. Gellens.

Date: August 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2645

This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK]

RFC 2646 The Text/Plain Format Parameter

Authors: R. Gellens, Ed..

Date: August 1999

Formats: txt json html

Obsoleted by: RFC 3676

Updates: RFC 2046

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2646

This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]

RFC 2647 Benchmarking Terminology for Firewall Performance

Authors: D. Newman.

Date: August 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2647

This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [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 2649 An LDAP Control and Schema for Holding Operation Signatures

Authors: B. Greenblatt, P. Richard.

Date: August 1999

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2649

In many environments clients require the ability to validiate the source and integrity of information provided by the directory. This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines anLDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. Both client and server based signatures are supported. An object class for subsequent retrieval are "journal entries" is also defined. This document specifies LDAP v3 controls that enable this functionality. It also defines an LDAP v3 schema that allows for subsequent browsing of the journal information.

RFC 2650 Using RPSL in Practice

Authors: D. Meyer, J. Schmitz, C. Orange, M. Prior, C. Alaettinoglu.

Date: August 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2650

This document is a tutorial on using the Routing Policy SpecificationLanguage (RPSL) to describe routing policies in the Internet RoutingRegistry (IRR). We explain how to specify various routing policies and configurations using RPSL, how to register these policies in theIRR, and how to analyze them using the routing policy analysis tools, for example to generate vendor specific router configurations.

RFC 2651 The Architecture of the Common Indexing Protocol (CIP)

Authors: J. Allen, M. Mealling.

Date: August 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2651

The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. Query routing is the process of redirecting and replicating queries through a distributed database system towards servers holding the desired results. This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices.

RFC 2652 MIME Object Definitions for the Common Indexing Protocol (CIP)

Authors: J. Allen, M. Mealling.

Date: August 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2652

The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. The protocol is comprised of several MIME objects being passed from server to server. This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type.

RFC 2653 CIP Transport Protocols

Authors: J. Allen, P. Leach, R. Hedberg.

Date: August 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2653

This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP.The objects themselves are defined in [CIP-MIME] and the overall CIP architecture is defined in [CIP-ARCH].

RFC 2654 A Tagged Index Object for use in the Common Indexing Protocol

Authors: R. Hedberg, B. Greenblatt, R. Moats, M. Wahl.

Date: August 1999

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2654

This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the CommonIndexing Protocol. It is assumed that the structures defined here can be used by X.500 DSAs, LDAP servers, Whois++ servers, CSO Ph servers and many others.

RFC 2655 CIP Index Object Format for SOIF Objects

Authors: T. Hardie, M. Bowman, D. Hardy, M. Schwartz, D. Wessels.

Date: August 1999

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2655

This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community.

RFC 2656 Registration Procedures for SOIF Template Types

Authors: T. Hardie.

Date: August 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2656

The Summary Object Interchange Format [Ref. 1] was first defined by the Harvest Project [Ref 2.] in January 1994. SOIF was derived from a combination of the Internet Anonymous FTP Archives IETF WorkingGroup (IAFA) templates [Ref 3.] and the BibTeX bibliography format[Ref 4.]. The combination was originally noted for its advantages of providing a convenient and intuitive way for delimiting objects within a stream, and setting apart the URL for easy object access or invocation, while still preserving compatibility with IAFA templates.
SOIF uses named template types to indicate the attributes which may be contained within a particular summary object. Within the context of a single application, private agreement on the definition of template types has been adequate. As SOIF objects are moved among applications, however, the need for standard, well-specified, and easily identifiable template types increases. This need is particularly intense in the context of query referral, where knowledge of an attribute's definition and the allowed data types for specific values is crucial. For a discussion of this in the context of the Common Indexing Protocol, see [Ref. 1].
The registration procedure described in this document is specific toSOIF template types. There is ongoing work within the IETF to specify a more generic schema registration facility[Ref. 5]. It is not yet clear whether the results of that work will encompass the ability to register entities like SOIF template types. If it does so, the registration of SOIF template types may be shifted to that method and registry. Should that occur, appropriate pointers will be created in cooperation with the Registrar to ensure that no registrations are lost.

RFC 2657 LDAPv2 Client vs

Authors: the Index Mesh. R. Hedberg.

Date: August 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2657

LDAPv2 clients as implemented according to RFC 1777 [1] have no notion on referral. The integration between such a client and anIndex Mesh, as defined by the Common Indexing Protocol [2], heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this.

RFC 2658 RTP Payload Format for PureVoice(tm) Audio

Authors: K. McKay.

Date: August 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2658

This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]

RFC 2659 Security Extensions For HTML

Authors: E. Rescorla, A. Schiffman.

Date: August 1999

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2659

This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. S-HTTP, as described by RFC 2660, contains the concept of negotiation headers which reflect the potential receiver of a message's preferences as to which crypto- graphic enhancements should be applied to the message. This document describes a syntax for binding these negotiation parameters to HTML anchors.
1. Introduction
2. Anchor Attributes
We define the following new anchor (and form submission) attributes:
DN -- The distinguished name of the principal for whom the request should be encrypted when dereferencing the anchor's url.This need not be specified, but failure to do so runs the risk that the client will be unable to determine the DN and therefore will be unable to encrypt. This should be specified in the form of RFC1485, using SGML quoting conventions as needed.
NONCE -- A free-format string (appropriately SGML quoted) which is to be included in a SHTTP-Nonce: header (after SGML quoting is removed) when the anchor is dereferenced.
CRYPTOPTS -- Cryptographic option information as described in
[SHTTP]. Specifically, the <cryptopt-list&rt; production.

RFC 2660 The Secure HyperText Transfer Protocol

Authors: E. Rescorla, A. Schiffman.

Date: August 1999

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 2660

This memo describes a syntax for securing messages sent using theHypertext Transfer Protocol (HTTP), which forms the basis for theWorld Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin.
The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction.

RFC 2661 Layer Two Tunneling Protocol "L2TP"

Authors: W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter.

Date: August 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2661

This document describes the Layer Two Tunneling Protocol (L2TP). STD51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications.

RFC 2662 Definitions of Managed Objects for the ADSL Lines

Authors: G. Bathrick, F. Ly.

Date: August 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2662

This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK]

RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations

Authors: P. Srisuresh, M. Holdrege.

Date: August 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2663

Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT.

RFC 2664 FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions

Authors: R. Plzak, A. Wells, E. Krol.

Date: August 1999

Formats: txt html json

Obsoletes: RFC 1594

Also: FYI 0004

Status: INFORMATIONAL

DOI: 10.17487/RFC 2664

This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. Unlike its predecessors, this edition seeks to answer the general questions that an unsophisticated consumer would ask as opposed to the more pointed questions of a more technically sophisticated Internet user. Those desiring a more in-depth discussion are directed to FYI 7 that deals with intermediate and advanced Q/A topics. A conscious effort has been made to keep this memo brief but at the same time provide the new user with enough information to generally understand theInternet.

RFC 2665 Definitions of Managed Objects for the Ethernet-like Interface Types

Authors: J. Flick, J. Johnson.

Date: August 1999

Formats: txt html json

Obsoletes: RFC 2358

Obsoleted by: RFC 3635

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2665

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2358, "Definitions of Managed Objects for theEthernet-like Interface Types". This memo extends that specification by including management information useful for the management of 1000Mb/s and full-duplex Ethernet interfaces.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology.

RFC 2666 Definitions of Object Identifiers for Identifying Ethernet Chip Sets

Authors: J. Flick.

Date: August 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2666

This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. In particular, it contains registered OID values for use with the dot3StatsEtherChipSet object in the EtherLike-MIB [16]. These registrations have been split from [16] into a separate document for maintenance purposes.

RFC 2667 IP Tunnel MIB

Authors: D. Thaler.

Date: August 1999

Formats: txt json html

Obsoleted by: RFC 4087

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2667

This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK]

RFC 2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)

Authors: A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts.

Date: August 1999

Formats: txt html json

Obsoletes: RFC 2239

Obsoleted by: RFC 3636

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2668

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2239, "Definitions of Managed Objects forIEEE 802.3 Medium Attachment Units (MAUs) using SMIv2". This memo extends that specification by including management information useful for the management of 1000 Mb/s MAUs.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology.

RFC 2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems

Authors: M. St. Johns, Ed..

Date: August 1999

Formats: txt html json

Obsoleted by: RFC 4639

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2669

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS 1.0 compliant Cable Modems and Cable ModemTermination Systems.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author.

RFC 2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces

Authors: M. St. Johns, Ed..

Date: August 1999

Formats: txt html json

Obsoleted by: RFC 4546

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2670

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects are consistent with theSNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author.

RFC 2671 Extension Mechanisms for DNS (EDNS0)

Authors: P. Vixie.

Date: August 1999

Formats: txt html json

Obsoleted by: RFC 6891

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2671

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.

RFC 2672 Non-Terminal DNS Name Redirection

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 2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions

Authors: E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie.

Date: August 1999

Formats: txt html json

Obsoleted by: RFC 4363

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2674

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular, it defines two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MACBridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'EnhancedMulticast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs.
Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes severalMIB modules in a manner that is compliant to the SMIv2 [V2SMI].
This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent)RFC 1525 [SBRIDGEMIB].

RFC 2675 IPv6 Jumbograms

Authors: D. Borman, S. Deering, R. Hinden.

Date: August 1999

Formats: txt html json

Obsoletes: RFC 2147

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2675

A "jumbogram" is an IPv6 packet containing a payload longer than65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms.
Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs.

RFC 2676 QoS Routing Mechanisms and OSPF Extensions

Authors: G. Apostolopoulos, S. Kama, D. Williams, R. Guerin, A. Orda, T. Przygienda.

Date: August 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2676

This memo describes extensions to the OSPF [Moy98] protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. Aspects related to how QoS routes are established and managed are also briefly discussed. The goal of this document is to identify a framework and possible approaches to allow deployment ofQoS routing capabilities with the minimum possible impact to the existing routing infrastructure.
In addition, experience from an implementation of the proposed extensions in the GateD environment [Con], along with performance measurements is presented.

RFC 2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)

Authors: M. Greene, J. Cucchiara, J. Luciani.

Date: August 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2677

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 the Next HopResolution Protocol (NHRP) as defined in RFC 2332.

RFC 2678 IPPM Metrics for Measuring Connectivity

Authors: J. Mahdavi, V. Paxson.

Date: September 1999

Formats: txt html json

Obsoletes: RFC 2498

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2678

This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]

RFC 2679 A One-way Delay Metric for IPPM

Authors: G. Almes, S. Kalidindi, M. Zekauskas.

Date: September 1999

Formats: txt html json

Obsoleted by: RFC 7679

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2679

This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]

RFC 2680 A One-way Packet Loss Metric for IPPM

Authors: G. Almes, S. Kalidindi, M. Zekauskas.

Date: September 1999

Formats: txt html json

Obsoleted by: RFC 7680

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2680

This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]

RFC 2681 A Round-trip Delay Metric for IPPM

Authors: G. Almes, S. Kalidindi, M. Zekauskas.

Date: September 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2681

This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]

RFC 2682 Performance Issues in VC-Merge Capable ATM LSRs

Authors: I. Widjaja, A. Elwalid.

Date: September 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2682

VC merging allows many routes to be mapped to the same VC label, thereby providing a scalable mapping method that can support thousands of edge routers. VC merging requires reassembly buffers so that cells belonging to different packets intended for the same destination do not interleave with each other. This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. The main result indicates that VC merging incurs a minimal overhead compared to non-VC merging in terms of additional buffering. Moreover, the overhead decreases as utilization increases, or as the traffic becomes more bursty.

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 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5

Authors: D. Grossman, J. Heinanen.

Date: September 1999

Formats: txt html json

Obsoletes: RFC 1483

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2684

This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM.The first method allows multiplexing of multiple protocols over a single ATM virtual connection whereas the second method assumes that each protocol is carried over a separate ATM virtual connection.

RFC 2685 Virtual Private Networks Identifier

Authors: B. Fox, B. Gleeson.

Date: September 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2685

Virtual Private IP networks may span multiple Autonomous Systems orService Providers. There is a requirement for the use of a globally unique VPN identifier in order to be able to refer to a particularVPN (see section 6.1.1 of [1]). This document proposes a format for a globally unique VPN identifier.

RFC 2686 The Multi-Class Extension to Multi-Link PPP

Authors: C. Bormann.

Date: September 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2686

A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
This document proposes the fragment-oriented solution for the real- time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol[2] and provide a small number of extensions to add functionality and reduce the overhead.

RFC 2687 PPP in a Real-time Oriented HDLC-like Framing

Authors: C. Bormann.

Date: September 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2687

A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol[2] and its multi-class extension [5] and add suspend/resume in a way that is as compatible to existing hard- and firmware as possible.

RFC 2688 Integrated Services Mappings for Low Speed Networks

Authors: S. Jackowski, D. Putzolu, E. Crawley, B. Davie.

Date: September 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2688

A set of companion documents describe an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1, 2, 3, 4]. The main components of the architecture are: a set of real-time encapsulation formats for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.
This document defines the service mappings of the IETF IntegratedServices for low-bitrate links, specifically the controlled load [5] and guaranteed [6] services. The approach takes the form of a set of guidelines and considerations for implementing these services, along with evaluation criteria for elements providing these services.

RFC 2689 Providing Integrated Services over Low-bitrate Links

Authors: C. Bormann.

Date: September 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2689

This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B- channels, and sub-T1 links. It covers only the lower parts of theInternet Multimedia Conferencing Architecture [1]; additional components required for application services such as InternetTelephony (e.g., a session initiation protocol) are outside the scope of this document. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low- bitrate links, a header compression architecture optimized for real- time flows, elements of negotiation protocols used between routers(or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place.

RFC 2690 A Proposal for an MOU-Based ICANN Protocol Support Organization

Authors: S. Bradner.

Date: September 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2690

This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999. This memo provides information for the Internet community.

RFC 2691 A Memorandum of Understanding for an ICANN Protocol Support Organization

Authors: S. Bradner.

Date: September 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2691

This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo. This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers(ICANN). This MoU was developed by representatives of the IETF, ITU,W3C, ETSI, and ICANN with the help of Jorge Contreras of Hale andDorr.
MEMORANDUM OF UNDERSTANDING
July 14, 1999
ICANN Protocol Supporting Organization
(1) Purpose and Scope
(a) The Protocol Support Organization (PSO) will be a consensus- based advisory body within the ICANN framework.
(b) The PSO will establish a "Protocol Council" and host an annual open meeting (the "General Assembly").
(c) The purpose of this Memorandum of Understanding (MOU) is to establish a set of principles that ICANN and the StandardsDevelopment Organizations who have signed below (the SigningSDOs) will use in forming and operating the PSO
(2) Composition and Action of Protocol Council
(a) Size. Each Signing SDO will appoint two (2) members to theProtocol Council, each such member to serve for a time period determined by such Signing SDO.
(b) Each Signing SDO shall be responsible for choosing its members of the Protocol Council in a manner of its own choosing, and in accordance with its own open procedures.Each Signing SDO may remove or replace one or both of its members on the Protocol Council in its discretion. EachSigning SDO must notify the Protocol Council Secretary andICANN when it changes its members and, in addition, must ratify its choices at least annually.
(c) Selection and Appointment. Concurrently with the posting of notice of the date of the annual meeting of the PSO GeneralAssembly on the PSO Web Site, ICANN and the Protocol Council shall make an open call for nominations to any potential vacancies on the Protocol Council. Any nominations received will be forwarded to the Signing SDOs eligible to appoint members (i.e., they do not already have two members on theProtocol Council) for their consideration.
(d) Action by Protocol Council. Unless otherwise specified in this MOU, all actions of the Protocol Council shall be taken by majority vote of the total number of members. Action may be taken at any meeting of the Protocol Council, which may be by telephone conference in which all participants can hear the others. Meetings of the Protocol Council may be called by request of any three members of the Protocol Council, with at least 45 days for physical meetings or fifteen (15) days for telephonic or other electronic meetings prior written notice to each of the other members. In order to conduct business at any meeting of the Protocol Council, at least a quorum of members must be present; a quorum shall be present when at least majority of the members of the Protocol Council are present, and when such members represent at least 3/4ths of the Signing SDOs.
(e) Web Site. The Protocol Council will arrange for the establishment and maintenance of a Web site devoted to PSO activities and news.
(f) Secretary. The Protocol Council will have a Secretary to coordinate administrative matters relating to the PSO andProtocol Council. The Secretary's term of office shall be one year. The position of Secretary will rotate among the
Signing SDOs, with the initial Secretary to be selected by the IETF, and subsequent Secretaries to be appointed by a randomly selected Signing SDO that has not appointed theSecretary in the current rotation.
(g) No Compensation. Neither the Secretary, nor any ProtocolCouncil member or designated ICANN Board member shall be entitled to any compensation or reimbursement of expenses from the PSO. The PSO shall not be required to obtain insurance coverage for, or to indemnify, the members of theProtocol Council or persons acting in any other capacity by or for the PSO.
(3) ICANN Directors
(a) The Protocol Council will appoint Directors to the ICANNBoard of Directors in accordance with the By-laws of ICANN, for such terms as are specified by such By-laws. ICANN will notify the Protocol Council of any vacancies on the ICANNBoard which may be filled by the Protocol Council.
(b) The Protocol Council will conduct an open call for nominations for any open PSO seats on the ICANN Board. EachSigning SDO is entitled to nominate candidates by procedures of its own choosing. Additionally, nominations from the public at large will be allowed under conditions to be defined by the Protocol Council. The Protocol Council will select the PSO nominees to the ICANN Board from among these nominees. ICANN Directors selected by the Protocol Council may, but need not, be members of the Protocol Council or anySDO.
(c) No more than 2 PSO-nominated Directors may be residents of the same Geographic Region (as defined in the ICANN By-laws).
(d) The ICANN Directors appointed by the Protocol Council will not represent the PSO on the ICANN Board, but will function as full Directors of ICANN.
(4) Duties of Protocol Council
(a) Advisory Role. The Protocol Council will advise the ICANNBoard on matters referred to the Protocol Council by theICANN Board relating to the assignment of parameters forInternet protocols.
(b) Policy Development
(i) In the tradition of the Internet, standards development policies and conflict resolution mechanisms should be created and utilized by those institutions most directly involved, without undue interference from centralized bodies.
(ii) The ICANN By-laws vest in the PSO the primary responsibility for developing and recommending substantive policies in the area of protocol parameter assignment.
(iii) The PSO is committed to the proposition that policies for parameter assignments for particular protocols are the responsibility of the individual Signing SDO that developed the protocol.
(iv) The Protocol Council, and, when requested, ICANN, will be available as needed by the Signing SDOs to develop policies and procedures for conflict resolution betweenSigning SDOs.
(v) Any such policies and procedures will be adopted only with the agreement of all SDOs.
(5) Annual Open Meeting
(a) The Protocol Council will periodically convene an open meeting ("General Assembly") for promoting discussion and receiving input regarding the work of the PSO.(b) A General Assembly will be held at least once per year, and will permit open participation by all interested individuals.(c) Each annual General Assembly will be hosted by a Signing SDO in conjunction with one of its major meetings, as determined by the Protocol Council (with an effort to hold no 2 consecutive General Assemblies in the same GeographicRegion.)(d) It is expected that the major organizations within theInternet protocol standards development community will provide the constituency of the General Assembly.
(6) Open Proceedings and Documents
(a) Communications between ICANN and the Protocol Council. All official communications between ICANN and the ProtocolCouncil will be made public on the PSO web site. In the event that ICANN requests that a communication be kept confidential, the Protocol Council will honor this request for a fixed period of time not to exceed one year, and then make the communication public.
(b) Protocol Council Proceedings. All meetings of the ProtocolCouncil and official discussions of Protocol Council business will be conducted or reported on a publicly-archived mailing list accessible through the PSO web site.
(c) Meeting Announcements. The schedule and agenda for the PSOGeneral Assembly will be posted on the PSO Web Site at least90 days in advance of the meeting date. Notice of ProtocolCouncil meetings will be posted on the PSO Web at least 45 days before each physical meeting or fifteen (15) days before any telephonic or other electronic meeting, or such shorter time period agreed upon by each of the Signing SDOs. The minutes from all PSO meetings will be publicly posted on thePSO web site within 30 days of the meeting.
(7) Review and Modification of MOU. ICANN and the Signing SDOs will periodically review the results and consequences of their cooperation under this MOU. When appropriate, the signatories will consider the need for improvements in the MOU and make suitable proposals for modifying and updating the arrangements and scope of the MOU. Any modification to the MOU must be approved by all signatories.
(8) Standards Development Organizations
(a) The initial signatories to this MOU shall include ICANN and the Signing SDOs who have signed below. Each Signing SDO must be an international, Internet-related standards development organization that establishes that it meets the criteria for SDOs set forth below.
(i) SDOs must be open, international, voluntary technical standard and technical specification development organizations which:
(A) Develop standards and/or specifications for use over the public Internet.
(B) Can demonstrate active membership in the IP-related standards and/or specification development process of more than 800 individuals, if individual memberships are used by the organization, or 80 companies, if corporate memberships are used by the organization.
(C) Has been in operation for 3 or more years at the time of their application.
(D) Can demonstrate that there is significant deployment of its standards on the Internet.
(E) The significant protocols controlled by the organization can be implemented without paying a licensing fee to the organization.
(ii) Open, international, voluntary standards organizations are defined as international organizations that plan, develop or establish voluntary standards. An organization shall be considered open and international if its standards and/or specifications development process is open to any person or organization of any nationality on equitable terms. An organization shall be considered voluntary if it makes no claim to compel use of its standards and specifications. Additionally, to be considered 'international', an organization's voting (or other "full") membership must include individuals or companies primarily located in at least three different Geographic Regions and at least two different countries within each of those GeographicRegions.
(b) New Signatories
(i) Any organization that believes it satisfies the SDO qualifications set forth above may apply in writing to the Protocol Council to become a party to this MOU.In order for an organization to become a party to thisMOU, all then-existing MOU signatories must agree that such organization qualifies as an SDO.
(ii) Rejected applicants can appeal to the ICANN Board, which may override such a rejection if the ICANN Board finds, by at least a two-thirds vote, that the organization meets the SDO criteria set forth above.
(iii) Any organization that is accepted as an SDO under thisMOU must execute a copy of this MOU, and agree to be bound by all of its terms and conditions, upon which it shall be considered a Signing SDO for all purposes under this MOU.
(9) General. This MOU does not constitute any of the parties as a partner, joint venture, agent, principal or franchisee of any other party. The waiver of any provision of this MOU on any occasion shall not constitute a waiver for purposes of any other occasion. No party may transfer or assign any interest, right or obligation arising under this MOU without the prior written consent of each other party to this MOU.
IN WITNESS WHEREOF, this Memorandum of Understanding is executed this 14 day of July 1999 by the undersigned, acting through their duly authorized representatives:
INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERSBy: (signature)Name: Michael W. RobertsTitle: Interim President / CEO
INTERNET ENGINEERING TASK FORCEBy: (signature)Name: Fredrick J. BakerTitle: Chair, IETF
INTERNATIONAL TELECOMMUNATIONS UNIONBy: (signature)Name: Houlin Zhao, on behalf of Secretary-General of ITUTitle: Director, TSB
WORLD WIDE WEB CONSORTIUMBy: (signature)Name: Henrik Frystyk NielsenTitle: HTTP Activity Lead
EUROPEAN TELECOMMUNICATIONS STANDARDS INSITITUTEBy: (signature)Name: Bridget CosgraveTitle: Deputy Director General

RFC 2692 SPKI Requirements

Authors: C. Ellison.

Date: September 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2692

The IETF Simple Public Key Infrastructure [SPKI] Working Group is tasked with producing a certificate structure and operating procedure to meet the needs of the Internet community for trust management in as easy, simple and extensible a way as possible.
The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements.

RFC 2693 SPKI Certificate Theory

Authors: C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen.

Date: September 1999

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2693

The SPKI Working Group has developed a standard form for digital certificates whose main purpose is authorization rather than authentication. These structures bind either names or explicit authorizations to keys or other objects. The binding to a key can be directly to an explicit key, or indirectly through the hash of the key or a name for it. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for thoseS-expressions. As part of this development, a mechanism for deriving authorization decisions from a mixture of certificate types was developed and is presented in this document.
This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses.

RFC 2694 DNS extensions to Network Address Translators (DNS_ALG)

Authors: P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan.

Date: September 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2694

Domain Name Service (DNS) provides name to address mapping within a routing class (ex: IP). Network Address Translators (NATs) attempt to provide transparent routing between hosts in disparate address realms of the same routing class. Typically, NATs exist at the border of a stub domain, hiding private addresses from external addresses. This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need.DNS_ALG modifies payload transparently to alter address mapping of hosts as DNS packets cross one address realm into another. The document also illustrates the operation of DNS_ALG with specific examples.

RFC 2695 Authentication Mechanisms for ONC RPC

Authors: A. Chiu.

Date: September 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2695

This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. This memo provides information for the Internet community.

RFC 2696 LDAP Control Extension for Simple Paged Results Manipulation

Authors: C. Weider, A. Herron, A. Anantha, T. Howes.

Date: September 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2696

This document describes an LDAPv3 control extension for simple paging of search results. This memo provides information for the Internet community.

RFC 2697 A Single Rate Three Color Marker

Authors: J. Heinanen, R. Guerin.

Date: September 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2697

This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner [RFC2475,RFC2474]. The srTCM meters a traffic stream and marks its packets according to three traffic parameters, Committed Information Rate(CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be either green, yellow, or red. A packet is marked green if it doesn't exceed the CBS, yellow if it does exceed the CBS, but not the EBS, and red otherwise.

RFC 2698 A Two Rate Three Color Marker

Authors: J. Heinanen, R. Guerin.

Date: September 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2698

This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner[RFC2475, RFC2474]. The trTCM meters an IP packet stream and marks its packets based on two rates, Peak Information Rate (PIR) andCommitted Information Rate (CIR), and their associated burst sizes to be either green, yellow, or red. A packet is marked red if it exceeds the PIR. Otherwise it is marked either yellow or green depending on whether it exceeds or doesn't exceed the CIR.

RFC 2699 Request for Comments Summary RFC Numbers 2600-2699

Authors: S. Ginoza.

Date: May 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2699

RFC 2700 Internet Official Protocol Standards

Authors: J. Reynolds, R. Braden.

Date: August 2000

Formats: txt html json

Obsoletes: RFC 2600

Obsoleted by: RFC 2800

Status: HISTORIC

DOI: 10.17487/RFC 2700

This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering TaskForce (IETF). Sections 3.1 - 3.6 contain the lists of protocols in each stage of standardization - Standard, Draft Standard, ProposedStandard, Experimental and Historic. Protocols that are new to this document or have been moved from one protocol level to another, or differ from the previous edition of this document are marked.Informational Request for Comments (RFCs) are not included. This memo lists the current protocols; it is not a complete index to RFCs.

RFC 2701 Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol

Authors: G. Malkin.

Date: September 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2701

This document specifies a standard way for Multi-link PPP to operate across multiple nodes. Both the mechanism by which the Bundle Head is discovered and the PPP fragment encapsulation are specified.

RFC 2702 Requirements for Traffic Engineering Over MPLS

Authors: D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus.

Date: September 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2702

This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. These capabilities can be used to optimize the utilization of network resources and to enhance traffic oriented performance characteristics.

RFC 2703 Protocol-independent Content Negotiation Framework

Authors: G. Klyne.

Date: September 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2703

A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1,2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers.
This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed.
The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The goals set out the desired properties of a content negotiation mechanism.

RFC 2704 The KeyNote Trust-Management System Version 2

Authors: M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis.

Date: September 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2704

This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. TheKeyNote architecture and language are useful as building blocks for the trust management aspects of a variety of Internet protocols and services.

RFC 2705 Media Gateway Control Protocol (MGCP) Version 1.0

Authors: M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett.

Date: October 1999

Formats: txt html json

Obsoleted by: RFC 3435

Updated by: RFC 3660

Status: INFORMATIONAL

DOI: 10.17487/RFC 2705

This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP)Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.
The document is structured in 6 main sections:
* The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP.
* The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP:Notifications Request, Notification, Create Connection, ModifyConnection, Delete Connection, AuditEndpoint, AuditConnection andRestartInProgress.
* The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP.
* The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC).
* The event packages section provides an initial definition of packages and event names.
* The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 1.0.

RFC 2706 ECML v1: Field Names for E-Commerce

Authors: D. Eastlake 3rd, T. Goldstein.

Date: October 1999

Formats: txt json html

Obsoleted by: RFC 3106

Status: INFORMATIONAL

DOI: 10.17487/RFC 2706

Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields.

RFC 2707 Job Monitoring MIB - V1.0

Authors: R. Bergman, T. Hastings, S. Isaacson, H. Lewis.

Date: November 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2707

This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job.This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners.

RFC 2708 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB

Authors: R. Bergman.

Date: November 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2708

This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the JobMonitoring MIB.

RFC 2709 Security Model with Tunnel-mode IPsec for NAT Domains

Authors: P. Srisuresh.

Date: October 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2709

There are a variety of NAT flavors, as described in [Ref 1]. Of the domains supported by NATs, only Realm-Specific IP clients are able to pursue end-to-end IPsec secure sessions. However, all flavors of NAT are capable of offering tunnel-mode IPsec security to private domain hosts peering with nodes in external realm. This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. A section is devoted to describing how security policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Also outlined are applications that can benefit from the Security Model described.

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 2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)

Authors: A. Medvinsky, M. Hur.

Date: October 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2712

This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS TRACK]

RFC 2713 Schema for Representing Java(tm) Objects in an LDAP Directory

Authors: V. Ryan, S. Seligman, R. Lee.

Date: October 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2713

This document defines the schema for representing Java(tm) objects in an LDAP directory [LDAPv3]. It defines schema elements to represent a Java serialized object [Serial], a Java marshalled object [RMI], aJava remote object [RMI], and a JNDI reference [JNDI].

RFC 2714 Schema for Representing CORBA Object References in an LDAP Directory

Authors: V. Ryan, R. Lee, S. Seligman.

Date: October 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2714

CORBA [CORBA] is the Common Object Request Broker Architecture defined by the Object Management Group. This document defines the schema for representing CORBA object references in an LDAP directory[LDAPv3].

RFC 2715 Interoperability Rules for Multicast Routing Protocols

Authors: D. Thaler.

Date: October 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2715

The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains.Specific instantiations of these rules are given for the DVMRP,MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only links. Future versions of these protocols, and any other multicast routing protocols, may describe their interoperability procedure by stating how the rules described herein apply to them.

RFC 2716 PPP EAP TLS Authentication Protocol

Authors: B. Aboba, D. Simon.

Date: October 1999

Formats: txt json html

Obsoleted by: RFC 5216

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2716

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community.

RFC 2717 Registration Procedures for URL Scheme Names

Authors: R. Petke, I. King.

Date: November 1999

Formats: txt json html

Obsoleted by: RFC 4395

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2717

This document defines the process by which new URL scheme names are registered.

RFC 2718 Guidelines for new URL Schemes

Authors: L. Masinter, H. Alvestrand, D. Zigmond, R. Petke.

Date: November 1999

Formats: txt html json

Obsoleted by: RFC 4395

Status: INFORMATIONAL

DOI: 10.17487/RFC 2718

A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet.This document provides guidelines for the definition of new URL schemes.

RFC 2719 Framework Architecture for Signaling Transport

Authors: L. Ong, I. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M. Holdrege, C. Sharp.

Date: October 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2719

This document defines an architecture framework and functional requirements for transport of signaling information over IP. The framework describes relationships between functional and physical entities exchanging signaling information, such as Signaling Gateways and Media Gateway Controllers. It identifies interfaces where signaling transport may be used and the functional and performance requirements that apply from existing Switched Circuit Network (SCN) signaling protocols.

RFC 2720 Traffic Flow Measurement: Meter MIB

Authors: N. Brownlee.

Date: October 1999

Formats: txt html json

Obsoletes: RFC 2064

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2720

The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'.
This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised.

RFC 2721 RTFM: Applicability Statement

Authors: N. Brownlee.

Date: October 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2721

This document provides an overview covering all aspects of RealtimeTraffic Flow Measurement, including its area of applicability and its limitations.

RFC 2722 Traffic Flow Measurement: Architecture

Authors: N. Brownlee, C. Mills, G. Ruth.

Date: October 1999

Formats: txt json html

Obsoletes: RFC 2063

Status: INFORMATIONAL

DOI: 10.17487/RFC 2722

This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within theInternet.

RFC 2723 SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups

Authors: N. Brownlee.

Date: October 1999

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2723

This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow.

RFC 2724 RTFM: New Attributes for Traffic Flow Measurement

Authors: S. Handelman, S. Stibler, N. Brownlee, G. Ruth.

Date: October 1999

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2724

The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes.
Extensions described include Address Attributes such as DSCodePoint,SourceASN and DestASN, and Group Attributes such as short-term bit rates and turnaround times. Quality of Service parameters forIntegrated Services are also discussed.

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 2726 PGP Authentication for RIPE Database Updates

Authors: J. Zsako.

Date: December 1999

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2726

This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. The proposal tries to be as general as possible as far as digital signing methods are concerned, however, it concentrates mainly on PGP, as the first method to be implemented. The proposal is the result of the discussions within the RIPE DBSEC Task Force.

RFC 2727 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees

Authors: J. Galvin.

Date: February 2000

Formats: txt json html

Obsoletes: RFC 2282

Obsoleted by: RFC 3777

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2727

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 2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal

Authors: R. Panabaker, S. Wegerif, D. Zigmond.

Date: November 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2728

This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS TRACK]

RFC 2729 Taxonomy of Communication Requirements for Large-scale Multicast Applications

Authors: P. Bagnall, R. Briscoe, A. Poppitt.

Date: December 1999

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2729

The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). It is very unlikely one protocol can achieve a compromise between the diverse requirements of all the parties involved in any LSMA. It is therefore necessary to understand the worst-case scenarios in order to minimize the range of protocols needed. Dynamic protocol adaptation is likely to be necessary which will require logic to map particular combinations of requirements to particular mechanisms. Standardizing the way that applications define their requirements is a necessary step towards this.Classification is a first step towards standardization.

RFC 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP)

Authors: S. Hanna, B. Patel, M. Shah.

Date: December 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2730

This document defines a protocol, Multicast Address Dynamic ClientAllocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers.

RFC 2731 Encoding Dublin Core Metadata in HTML

Authors: J. Kunze.

Date: December 1999

Formats: txt html json

Obsoleted by: RFC 5791

Status: INFORMATIONAL

DOI: 10.17487/RFC 2731

The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community.

RFC 2732 Format for Literal IPv6 Addresses in URL's

Authors: R. Hinden, B. Carpenter, L. Masinter.

Date: December 1999

Formats: txt json html

Obsoleted by: RFC 3986

Updates: RFC 2396

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2732

This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx. It is also intended to be used in the IPv6 version of the service location protocol.
This document incudes an update to the generic syntax for UniformResource Identifiers defined in RFC 2396 [URL]. It defines a syntax for IPv6 addresses and allows the use of "[" and "]" within a URI explicitly for this reserved purpose.

RFC 2733 An RTP Payload Format for Generic Forward Error Correction

Authors: J. Rosenberg, H. Schulzrinne.

Date: December 1999

Formats: txt json html

Obsoleted by: RFC 5109

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2733

This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions.

RFC 2734 IPv4 over IEEE 1394

Authors: P. Johansson.

Date: December 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2734

This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS TRACK]

RFC 2735 NHRP Support for Virtual Private Networks

Authors: B. Fox, B. Petri.

Date: December 1999

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2735

The NBMA Next Hop Resolution Protocol (NHRP) is used to determine theNBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address (see [1]). This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network.

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 2737 Entity MIB (Version 2)

Authors: K. McCloghrie, A. Bierman.

Date: December 1999

Formats: txt json html

Obsoletes: RFC 2037

Obsoleted by: RFC 4133

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2737

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent.

RFC 2738 Corrections to "A Syntax for Describing Media Feature Sets"

Authors: G. Klyne.

Date: December 1999

Formats: txt html json

Updates: RFC 2533

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2738

In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.
This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates.

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 2740 OSPF for IPv6

Authors: R. Coltun, D. Ferguson, J. Moy.

Date: December 1999

Formats: txt json html

Obsoleted by: RFC 5340

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2740

This document describes the modifications to OSPF to support version6 of the Internet Protocol (IPv6). The fundamental mechanisms ofOSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.
Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header andEncapsulating Security Payload.
Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed.In addition, option handling has been made more flexible.
All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF(MOSPF) are also supported in OSPF for IPv6.

RFC 2741 Agent Extensibility (AgentX) Protocol Version 1

Authors: M. Daniele, B. Wijnen, M. Ellison, D. Francisco.

Date: January 2000

Formats: txt json html

Obsoletes: RFC 2257

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2741

This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processesSNMP protocol messages. This memo obsoletes RFC 2257.

RFC 2742 Definitions of Managed Objects for Extensible SNMP Agents

Authors: L. Heintz, S. Gudur, M. Ellison.

Date: January 2000

Formats: txt html json

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2742

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects managing SNMP agents that use theAgent Extensibility (AgentX) Protocol.
This memo specifies a MIB module in a manner that is both compliant to the SMIv2, and semantically identical to the peer SMIv1 definitions.

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 2745 RSVP Diagnostic Messages

Authors: A. Terzis, B. Braden, S. Vincent, L. Zhang.

Date: January 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2745

This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. This specification describes the functionality, diagnostic message formats, and processing rules.

RFC 2746 RSVP Operation Over IP Tunnels

Authors: A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang.

Date: January 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2746

This document describes an approach for providing RSVP protocol services over IP tunnels. We briefly describe the problem, the characteristics of possible solutions, and the design goals of our approach. We then present the details of an implementation which meets our design goals.

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 2749 COPS usage for RSVP

Authors: S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry.

Date: January 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2749

This document describes usage directives for supporting COPS policy services in RSVP environments.

RFC 2750 RSVP Extensions for Policy Control

Authors: S. Herzog.

Date: January 2000

Formats: txt json html

Updates: RFC 2205

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2750

This memo presents a set of extensions for supporting generic policy based admission control in RSVP. It should be perceived as an extension to the RSVP functional specifications [RSVP]
These extensions include the standard format of POLICY_DATA objects, and a description of RSVP's handling of policy events.
This document does not advocate particular policy control mechanisms; however, a Router/Server Policy Protocol description for these extensions can be found in [RAP, COPS, COPS-RSVP].

RFC 2751 Signaled Preemption Priority Policy Element

Authors: S. Herzog.

Date: January 2000

Formats: txt json html

Obsoleted by: RFC 3181

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2751

This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and[COPS]).
Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow.

RFC 2752 Identity Representation for RSVP

Authors: S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog.

Date: January 2000

Formats: txt html json

Obsoleted by: RFC 3182

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2752

This document describes the representation of identity information inPOLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner.We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting.

RFC 2753 A Framework for Policy-based Admission Control

Authors: R. Yavatkar, D. Pendarakis, R. Guerin.

Date: January 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2753

This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community.

RFC 2754 RPS IANA Issues

Authors: C. Alaettinoglu, C. Villamizar, R. Govindan.

Date: January 2000

Formats: txt json html

Obsoleted by: RFC 6254

Status: HISTORIC

DOI: 10.17487/RFC 2754

RPS Security [2] requires certain RPSL [1] objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required fromIANA.

RFC 2755 Security Negotiation for WebNFS

Authors: A. Chiu, M. Eisler, B. Callaghan.

Date: January 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2755

This document describes a protocol for a WebNFS client [RFC2054] to negotiate the desired security mechanism with a WebNFS server[RFC2055] before the WebNFS client falls back to the MOUNT v3 protocol [RFC1813]. This document is provided so that people can write compatible implementations.

RFC 2756 Hyper Text Caching Protocol (HTCP/0.0)

Authors: P. Vixie, D. Wessels.

Date: January 2000

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2756

This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions.

RFC 2757 Long Thin Networks

Authors: G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya.

Date: January 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2757

In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks.
Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind.
We recognize that not every tcpsat recommendation will be required for long thin networks as well, and work toward a set of TCP recommendations that are 'benign' in environments that do not require them.

RFC 2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring

Authors: K. White.

Date: February 2000

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2758

This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. The MIB defined herein focuses on defining a set of objects for monitoring SLAs and not on replication of the content of the policy definitions being monitored. The goal of the MIB defined within this document is to defined statistics related to a policy rule definition for reporting on the effect that a policy rule has on a system and to defined a method of monitoring this data.

RFC 2759 Microsoft PPP CHAP Extensions, Version 2

Authors: G. Zorn.

Date: January 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2759

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 and a family of NetworkControl Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document describes version two of Microsoft's PPP CHAP dialect(MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1, described in [9]). In particular, certain protocol fields have been deleted or reused but with different semantics. In addition, MS-CHAP-V2 features mutual authentication.
The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in section 8. Negotiation and hash generation examples are provided in section 9.

RFC 2760 Ongoing TCP Research Related to Satellites

Authors: M. Allman, Ed., S. Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke.

Date: February 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2760

This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by theIETF. The goal of this document is to educate researchers as to the current work and progress being done in TCP research related to satellite networks.

RFC 2761 Terminology for ATM Benchmarking

Authors: J. Dunn, C. Martin.

Date: February 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2761

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context ofAsynchronous Transfer Mode (ATM) based switching devices. The terms defined in this memo will be used in addition to terms defined inRFCs 1242, 2285, and 2544. This memo is a product of the BenchmarkingMethodology Working Group (BMWG) of the Internet Engineering TaskForce (IETF).

RFC 2762 Sampling of the Group Membership in RTP

Authors: J. Rosenberg, H. Schulzrinne.

Date: February 2000

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2762

In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered.

RFC 2763 Dynamic Hostname Exchange Mechanism for IS-IS

Authors: N. Shen, H. Smit.

Date: February 2000

Formats: txt html json

Obsoleted by: RFC 5301

Status: INFORMATIONAL

DOI: 10.17487/RFC 2763

Currently, there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network.

RFC 2764 A Framework for IP Based Virtual Private Networks

Authors: B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis.

Date: February 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2764

This document describes a framework for Virtual Private Networks(VPNs) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions.

RFC 2765 Stateless IP/ICMP Translation Algorithm (SIIT)

Authors: E. Nordmark.

Date: February 2000

Formats: txt json html

Obsoleted by: RFC 6145

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2765

This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts.

RFC 2766 Network Address Translation - Protocol Translation (NAT-PT)

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 2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)

Authors: K. Tsuchiya, H. Higuchi, Y. Atarashi.

Date: February 2000

Formats: txt html json

Obsoleted by: RFC 6535

Status: INFORMATIONAL

DOI: 10.17487/RFC 2767

In the especially initial stage of the transition from IPv4 to IPv6, it is hard to provide a complete set of IPv6 applications. This memo proposes a mechanism of dual stack hosts using the technique called"Bump-in-the-Stack" in the IP security area. The mechanism allows the hosts to communicate with other IPv6 hosts using existing IPv4 applications.

RFC 2768 Network Policy and Services: A Report of a Workshop on Middleware

Authors: B. Aiken, J. Strassner, B. Carpenter, I. Foster, C. Lynch, J. Mambretti, R. Moore, B. Teitelbaum.

Date: February 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2768

An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The Workshop was organized and sponsored by Cisco, Northwestern University'sInternational Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal of the workshop was to identify existing middleware services that could be leveraged for new capabilities as well as identifying additional middleware services requiring research and development. The workshop participants discussed the definition of middleware in general, examined the applications perspective, detailed underlying network transport capabilities relevant to middleware services, and then covered various specific examples of middleware components. These included APIs, authentication, authorization, and accounting (AAA) issues, policy framework, directories, resource management, networked information discovery and retrieval services, quality of service, security, and operational tools. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified.

RFC 2769 Routing Policy System Replication

Authors: C. Villamizar, C. Alaettinoglu, R. Govindan, D. Meyer.

Date: February 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2769

The RIPE database specifications and RPSL 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 use. The Routing Policy System Security RFC [3] addresses the need to assure integrity of the data by proposing an authentication and authorization model. This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System SecurityRFC.

RFC 2770 GLOP Addressing in 233/8

Authors: D. Meyer, P. Lothberg.

Date: February 2000

Formats: txt json html

Obsoleted by: RFC 3180

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2770

This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]).
This memo is a product of the Multicast Deployment Working Group(MBONED) in the Operations and Management Area of the InternetEngineering Task Force. Submit comments to <mboned@ns.uoregon.edu&rt; or the authors.

RFC 2771 An Abstract API for Multicast Address Allocation

Authors: R. Finlayson.

Date: February 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2771

This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications.
Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service.

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 2773 Encryption using KEA and SKIPJACK

Authors: R. Housley, P. Yee, W. Nace.

Date: February 2000

Formats: txt html json

Updates: RFC 0959

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2773

This document defines a method to encrypt a file transfer using theFTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)",(October 1985) [3] and RFC 2228, "FTP Security Extensions" (October1997) [1]. This method will use the Key Exchange Algorithm (KEA) to give mutual authentication and establish the data encryption keys.SKIPJACK is used to encrypt file data and the FTP command channel.

RFC 2774 An HTTP Extension Framework

Authors: H. Nielsen, P. Leach, S. Lawrence.

Date: February 2000

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 2774

A wide range of applications have proposed various extensions of theHTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.

RFC 2775 Internet Transparency

Authors: B. Carpenter.

Date: February 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2775

This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer.
This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations.

RFC 2776 Multicast-Scope Zone Announcement Protocol (MZAP)

Authors: M. Handley, D. Thaler, R. Kermode.

Date: February 2000

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 2776

This document defines a protocol, the Multicast-Scope ZoneAnnouncement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. MZAP also provides mechanisms whereby common misconfigurations of administrative scope zones can be discovered.

RFC 2777 Publicly Verifiable Nomcom Random Selection

Authors: D. Eastlake 3rd.

Date: February 2000

Formats: txt html json

Obsoleted by: RFC 3797

Status: INFORMATIONAL

DOI: 10.17487/RFC 2777

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee from the pool of eligible volunteers is used.Similar techniques would be applicable to other cases.

RFC 2778 A Model for Presence and Instant Messaging

Authors: M. Day, J. Rosenberg, H. Sugano.

Date: February 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2778

This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging.

RFC 2779 Instant Messaging / Presence Protocol Requirements

Authors: M. Day, S. Aggarwal, G. Mohr, J. Vincent.

Date: February 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2779

Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.
Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and PresenceProtocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.

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 2781 UTF-16, an encoding of ISO 10646

Authors: P. Hoffman, F. Yergeau.

Date: February 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2781

This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides information for the Internet community.

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 2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0

Authors: J. Mogul, D. Mills, J. Brittenson, J. Stone, U. Windl.

Date: March 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2783

RFC 1589 describes a UNIX kernel implementation model for high- precision time-keeping. This model is meant for use in conjunction with the Network Time Protocol (NTP, RFC 1305), or similar time synchronization protocols. One aspect of this model is an accurate interface to the high-accuracy, one pulse-per-second (PPS) output typically available from precise time sources (such as a GPS or GOES receiver). RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API.

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 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME

Authors: R. Zuccherato.

Date: March 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2785

In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks.

RFC 2786 Diffie-Helman USM Key Management Information Base and Textual Convention

Authors: M. St. Johns.

Date: March 2000

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2786

This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges and a set of objects which extend the usmUserTable to permit the use of aDH key exchange in addition to the key change method described in[12]. In otherwords, this MIB adds the possibility of forward secrecy to the USM model. It also defines a set of objects that can be used to kick start security on an SNMPv3 agent when the out of band path is authenticated, but not necessarily private or confidential.
The KeyChange textual convention described in [12] permits secure key changes, but has the property that if a third-party has knowledge of the original key (e.g. if the agent was manufactured with a standard default key) and could capture all SNMP exchanges, the third-party would know the new key. The Diffie-Helman key change described here limits knowledge of the new key to the agent and the manager making the change. In otherwords, this process adds forward secrecy to the key change process.
The recommendation in [12] is that the usmUserTable be populated out of band - e.g. not via SNMP. If the number of agents to be configured is small, this can be done via a console port and manually. If the number of agents is large, as is the case for a cable modem system, the manual approach doesn't scale well. The combination of the two mechanisms specified here - the DH key change mechanism, and the DH key ignition mechanism - allows managable use of SNMPv3 USM in a system of millions of devices.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards and is intended for use with the SNMPv3 User Security Model MIB and other security related MIBs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [16].
This memo is a private submission by the author, but is applicable to the SNMPv3 working group within the Internet Engineering Task Force.Comments are solicited and should be addressed to the the author.

RFC 2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol

Authors: B. Jewell, D. Chuang.

Date: March 2000

Formats: txt html json

Obsoleted by: RFC 6527

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2787

This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router RedundancyProtocol (VRRP) [17].
This memo specifies a MIB module in a manner that is compliant withSMIv2 [5], and semantically identical to the SMIv1 definitions [2].

RFC 2788 Network Services Monitoring MIB

Authors: N. Freed, S. Kille.

Date: March 2000

Formats: txt json html

Obsoletes: RFC 2248

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2788

This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS TRACK]

RFC 2789 Mail Monitoring MIB

Authors: N. Freed, S. Kille.

Date: March 2000

Formats: txt json html

Obsoletes: RFC 2249, RFC 1566

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2789

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [16] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS TRACK]

RFC 2790 Host Resources MIB

Authors: S. Waldbusser, P. Grillo.

Date: March 2000

Formats: txt json html

Obsoletes: RFC 1514

Status: DRAFT STANDARD

DOI: 10.17487/RFC 2790

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the HostResources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB.
This memo defines a MIB for use with managing host systems. The term"host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services(e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix.

RFC 2791 Scalable Routing Design Principles

Authors: J. Yu.

Date: July 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2791

Routing is essential to a network. Routing scalability is essential to a large network. When routing does not scale, there is a direct impact on the stability and performance of a network. Therefore, routing scalability is an important issue, especially for a large network. This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks.

RFC 2792 DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System

Authors: M. Blaze, J. Ioannidis, A. Keromytis.

Date: March 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2792

This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system.

RFC 2793 RTP Payload for Text Conversation

Authors: G. Hellstrom.

Date: May 2000

Formats: txt html json

Obsoleted by: RFC 4103

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2793

This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified inITU-T Recommendation T.140 [1].
Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services.
This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198.

RFC 2794 Mobile IP Network Access Identifier Extension for IPv4

Authors: P. Calhoun, C. Perkins.

Date: March 2000

Formats: txt json html

Updates: RFC 2290

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2794

AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers.Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero.

RFC 2795 The Infinite Monkey Protocol Suite (IMPS)

Authors: S. Christey.

Date: 1 April 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2795

This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works ofWilliam Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them.

RFC 2796 BGP Route Reflection - An Alternative to Full Mesh IBGP

Authors: T. Bates, R. Chandra, E. Chen.

Date: April 2000

Formats: txt html json

Obsoleted by: RFC 4456

Updates: RFC 1966

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2796

The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within thatAS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].
This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP.

RFC 2797 Certificate Management Messages over CMS

Authors: M. Myers, X. Liu, J. Schaad, J. Weinstein.

Date: April 2000

Formats: txt html json

Obsoleted by: RFC 5272

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2797

This document defines a Certificate Management protocol using CMS(CMC). This protocol addresses two immediate needs within theInternet PKI community:
1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and2. The need in [SMIMEV3] for a certificate enrollment protocol forDSA-signed certificates with Diffie-Hellman public keys.
A small number of additional services are defined to supplement the core certificate request service.
Throughout this specification the term CMS is used to refer to both[CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification.

RFC 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 2799 Request for Comments Summary RFC Numbers 2700-2799

Authors: S. Ginoza.

Date: September 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2799

RFC 2800 Internet Official Protocol Standards

Authors: J. Reynolds, R. Braden, S. Ginoza.

Date: May 2001

Formats: txt html json

Obsoletes: RFC 2700

Obsoleted by: RFC 2900

Status: HISTORIC

DOI: 10.17487/RFC 2800

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to theRFC series. The latest version of this memo is designated STD 1.

RFC 2801 Internet Open Trading Protocol - IOTP Version 1.0

Authors: D. Burdett.

Date: April 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2801

The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Secure ChannelCredit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, thePayment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party.

RFC 2802 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)

Authors: K. Davidson, Y. Kawatsura.

Date: April 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2802

A syntax and procedures are described for the computation and verification of digital signatures for use within Version 1.0 of theInternet Open Trading Protocol (IOTP).

RFC 2803 Digest Values for DOM (DOMHASH)

Authors: H. Maruyama, K. Tamura, N. Uramoto.

Date: April 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2803

This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This definition can be used for XML digital signature as well efficient replication of XML objects.

RFC 2804 IETF Policy on Wiretapping

Authors: IAB, IESG.

Date: May 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2804

The Internet Engineering Task Force (IETF) has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping.
This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means.

RFC 2805 Media Gateway Control Protocol Architecture and Requirements

Authors: N. Greene, M. Ramalho, B. Rosen.

Date: April 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2805

This document describes protocol requirements for the Media GatewayControl Protocol between a Media Gateway Controller and a MediaGateway.

RFC 2806 URLs for Telephone Calls

Authors: A. Vaha-Sipila.

Date: April 2000

Formats: txt json html

Obsoleted by: RFC 3966

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2806

This document specifies URL (Uniform Resource Locator) schemes "tel","fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. This specification covers voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, both for POTS and digital/mobile subscribers.

RFC 2807 XML Signature Requirements

Authors: J. Reagle.

Date: July 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2807

This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination.

RFC 2808 The SecurID(r) SASL Mechanism

Authors: M. Nystrom.

Date: April 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2808

SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication. This document defines a SASL [RFC2222] authentication mechanism using these tokens, thereby providing a means for such tokens to be used in SASL environments. This mechanism is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services.
This memo assumes the reader has basic familiarity with the SecurID token, its associated authentication protocol and SASL.

RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS

Authors: B. Aboba, G. Zorn.

Date: April 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2809

This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using theL2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents.

RFC 2810 Internet Relay Chat: Architecture

Authors: C. Kalt.

Date: April 2000

Formats: txt html json

Updates: RFC 1459

Status: INFORMATIONAL

DOI: 10.17487/RFC 2810

The IRC (Internet Relay Chat) protocol is for use with text based conferencing. It has been developed since 1989 when it was originally implemented as a mean for users on a BBS to chat amongst themselves.
First formally documented in May 1993 by RFC 1459 [IRC], the protocol has kept evolving. This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here.

RFC 2811 Internet Relay Chat: Channel Management

Authors: C. Kalt.

Date: April 2000

Formats: txt html json

Updates: RFC 1459

Status: INFORMATIONAL

DOI: 10.17487/RFC 2811

One of the most notable characteristics of the IRC (Internet RelayChat) protocol is to allow for users to be grouped in forums, called channels, providing a mean for multiple users to communicate together.
There was originally a unique type of channels, but with the years, new types appeared either as a response to a need, or for experimental purposes.
This document specifies how channels, their characteristics and properties are managed by IRC servers.

RFC 2812 Internet Relay Chat: Client Protocol

Authors: C. Kalt.

Date: April 2000

Formats: txt json html

Updates: RFC 1459

Status: INFORMATIONAL

DOI: 10.17487/RFC 2812

The IRC (Internet Relay Chat) protocol is for use with text based conferencing; the simplest client being any socket program capable of connecting to the server.
This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture [IRC-ARCH].

RFC 2813 Internet Relay Chat: Server Protocol

Authors: C. Kalt.

Date: April 2000

Formats: txt json html

Updates: RFC 1459

Status: INFORMATIONAL

DOI: 10.17487/RFC 2813

While based on the client-server model, the IRC (Internet Relay Chat) protocol allows servers to connect to each other effectively forming a network.
This document defines the protocol used by servers to talk to each other. It was originally a superset of the client protocol but has evolved differently.
First formally documented in May 1993 as part of RFC 1459 [IRC], most of the changes brought since then can be found in this document as development was focused on making the protocol scale better. Better scalability has allowed existing world-wide networks to keep growing and reach sizes which defy the old specification.

RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks

Authors: R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer.

Date: May 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2814

This document describes a signaling method and protocol for RSVP- based admission control over IEEE 802-style LANs. The protocol is designed to work both with the current generation of IEEE 802 LANs as well as with the recent work completed by the IEEE 802.1 committee.

RFC 2815 Integrated Service Mappings on IEEE 802 Networks

Authors: M. Seaman, A. Smith, E. Crawley, J. Wroclawski.

Date: May 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2815

This document describes mappings of IETF Integrated Services overLANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). It describes parameter mappings for supporting Controlled Load and Guaranteed Service using the inherent capabilities of relevant IEEE 802 technologies and, in particular, 802.1D-1998 queuing features in switches.
These mappings are one component of the Integrated Services over IEEE802 LANs framework.

RFC 2816 A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies

Authors: A. Ghanwani, J. Pace, V. Srinivasan, A. Smith, M. Seaman.

Date: May 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2816

This memo describes a framework for supporting IETF IntegratedServices on shared and switched LAN infrastructure. It includes background material on the capabilities of IEEE 802 like networks with regard to parameters that affect Integrated Services such as access latency, delay variation and queuing support in LAN switches.It discusses aspects of IETF's Integrated Services model that cannot easily be accommodated in different LAN environments. It outlines a functional model for supporting the Resource Reservation Protocol(RSVP) in such LAN environments. Details of extensions to RSVP for use over LANs are described in an accompanying memo [14]. Mappings of the various Integrated Services onto IEEE 802 LANs are described in another memo [13].

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 2819 Remote Network Monitoring Management Information Base

Authors: S. Waldbusser.

Date: May 2000

Formats: txt html json

Obsoletes: RFC 1757

Also: STD 0059

Status: INTERNET STANDARD

DOI: 10.17487/RFC 2819

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.
This memo obsoletes RFC 1757. This memo extends that specification by documenting the RMON MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB.

RFC 2820 Access Control Requirements for LDAP

Authors: E. Stokes, D. Byrne, B. Blakley, P. Behera.

Date: May 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2820

This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory ApplicationProtocol (LDAP) directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories.
The keywords "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97].

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 2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing

Authors: J. Carlson, P. Langner, E. Hernandez-Valencia, J. Manchester.

Date: May 2000

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2823

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links, andRFCs 1662 [2] and 2615 [3] provide a means to carry PPP overSynchronous Optical Network (SONET) [4] and Synchronous DigitalHierarchy (SDH) [5] circuits. This document extends these standards to include a new encapsulation for PPP called Simple Data Link (SDL)[6]. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links.

RFC 2824 Call Processing Language Framework and Requirements

Authors: J. Lennox, H. Schulzrinne.

Date: May 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2824

A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This document describes an architectural framework for such a mechanism, which we call a call processing language. It also outlines requirements for such a language.

RFC 2825 A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols

Authors: IAB, L. Daigle, Ed..

Date: May 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2825

The goals of the work to "internationalize" Internet protocols include providing all users of the Internet with the capability of using their own language and its standard character set to express themselves, write names, and to navigate the network. This impacts the domain names visible in e-mail addresses and so many of today'sURLs used to locate information on the World Wide Web, etc. However, domain names are used by Internet protocols that are used across national boundaries. These services must interoperate worldwide, or we risk isolating components of the network from each other along locale boundaries. This type of isolation could impede not only communications among people, but opportunities of the areas involved to participate effectively in e-commerce, distance learning, and other activities at an international scale, thereby retarding economic development.
There are several proposals for internationalizing domain names, however it it is still to be determined whether any of them will ensure this interoperability and global reach while addressing visible-name representation. Some of them obviously do not. This document does not attempt to review any specific proposals, as that is the work of the Internationalized Domain Name (IDN) Working Group of the IETF, which is tasked with evaluating them in consideration of the continued global network interoperation that is the deserved expectation of all Internet users.
This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces.

RFC 2826 IAB Technical Comment on the Unique DNS Root

Authors: Internet Architecture Board.

Date: May 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2826

This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community.

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 2828 Internet Security Glossary

Authors: R. Shirey.

Date: May 2000

Formats: txt html json

Obsoleted by: RFC 4949

Status: INFORMATIONAL

DOI: 10.17487/RFC 2828

This Glossary (191 pages of definitions and 13 pages of references) provides abbreviations, explanations, and recommendations for use of information system security terminology. The intent is to improve the comprehensibility of writing that deals with Internet security, particularly Internet Standards documents (ISDs). To avoid confusion,ISDs should use the same term or definition whenever the same concept is mentioned. To improve international understanding, ISDs should use terms in their plainest, dictionary sense. ISDs should use terms established in standards documents and other well-founded publications and should avoid substituting private or newly made-up terms. ISDs should avoid terms that are proprietary or otherwise favor a particular vendor, or that create a bias toward a particular security technology or mechanism versus other, competing techniques that already exist or might be developed in the future.

RFC 2829 Authentication Methods for LDAP

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 2831 Using Digest Authentication as a SASL Mechanism

Authors: P. Leach, C. Newman.

Date: May 2000

Formats: txt html json

Obsoleted by: RFC 6331

Status: HISTORIC

DOI: 10.17487/RFC 2831

This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5[RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols.

RFC 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 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

Authors: H. Schulzrinne, S. Petrack.

Date: May 2000

Formats: txt json html

Obsoleted by: RFC 4733, RFC 4734

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2833

This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets.

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 2836 Per Hop Behavior Identification Codes

Authors: S. Brim, B. Carpenter, F. Le Faucheur.

Date: May 2000

Formats: txt json html

Obsoleted by: RFC 3140

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2836

This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS TRACK]

RFC 2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard

Authors: K. Teow.

Date: May 2000

Formats: txt json html

Obsoleted by: RFC 4044

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2837

This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre ChannelStandards.

RFC 2838 Uniform Resource Identifiers for Television Broadcasts

Authors: D. Zigmond, M. Vickers.

Date: May 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2838

This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in RFC 2396. This memo provides information for the Internet community.

RFC 2839 Internet Kermit Service

Authors: F. da Cruz, J. Altman.

Date: May 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2839

This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. This memo provides information for the Internet community.

RFC 2840 TELNET KERMIT OPTION

Authors: J. Altman, F. da Cruz.

Date: May 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2840

This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. This memo provides information for the Internet community.

RFC 2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)

Authors: P. Metzger, W. Simpson.

Date: November 2000

Formats: txt json html

Obsoletes: RFC 1852

Status: HISTORIC

DOI: 10.17487/RFC 2841

This document describes the use of keyed SHA1 with the IPAuthentication Header.

RFC 2842 Capabilities Advertisement with BGP-4

Authors: R. Chandra, J. Scudder.

Date: May 2000

Formats: txt html json

Obsoleted by: RFC 3392

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2842

Currently BGP-4 [BGP-4] requires that when a BGP speaker receives anOPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP.
This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities inBGP by providing graceful capability advertisement without requiring that BGP peering be terminated.

RFC 2843 Proxy-PAR

Authors: P. Droz, T. Przygienda.

Date: May 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2843

Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that gives ATM-attached devices the ability to interact with PNNI devices without the necessity to fully support PAR. Proxy-PAR is designed as a client/server interaction, of which the client side is much simpler than the server side to allow fast implementation and deployment.
The purpose of Proxy-PAR is to allow non-ATM devices to use the flooding mechanisms provided by PNNI for registration and automatic discovery of services offered by ATM attached devices. The first version of PAR primarily addresses protocols available in IPv4. But it also contains a generic interface to access the flooding of PNNI.In addition, Proxy-PAR-capable servers provide filtering based on VPNIDs [1], IP protocols and address prefixes. This enables, for instance, routers in a certain VPN running OSPF to find OSPF neighbors on the same subnet. The protocol is built using a registration/query approach where devices can register their services and query for services and protocols registered by other clients.

RFC 2844 OSPF over ATM and Proxy-PAR

Authors: T. Przygienda, P. Droz, R. Haas.

Date: May 2000

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2844

This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy-PAR. These recommendations require no protocol changes and allow simpler, more efficient and cost- effective network designs. It is recommended that OSPF implementations should be able to support logical interfaces, each consisting of one or more virtual circuits and used either as numbered logical point-to-point links (one VC), logical NBMA networks(more than one VC) or Point-to-MultiPoint networks (more than oneVC), where a solution simulating broadcast interfaces is not appropriate. PAR can help distribute across the ATM cloud configuration setup and changes of such interfaces when OSPF capable routers are (re-)configured. Proxy-PAR can in turn be used to exchange this information between the ATM cloud and the routers connected to it.

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 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM

Authors: M. Eisler.

Date: June 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2847

This memorandum describes a method whereby one can use GSS-API[RFC2078] to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. As such, it is analogous to the common low infrastructure usage of the Transport Layer Security (TLS) protocol[RFC2246].
The method leverages the existing Simple Public Key Mechanism (SPKM)[RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY) layered above SPKM.

RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services

Authors: S. Petrack, L. Conroy.

Date: June 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2848

This document contains the specification of the PINT Service Protocol1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols.

RFC 2849 The LDAP Data Interchange Format (LDIF) - Technical Specification

Authors: G. Good.

Date: June 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2849

This document describes a file format suitable for describing directory information or modifications made to directory information.The file format, known as LDIF, for LDAP Data Interchange Format, is typically used to import and export directory information betweenLDAP-based directory servers, or to describe a set of changes which are to be applied to a directory.

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 2851 Textual Conventions for Internet Network Addresses

Authors: M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder.

Date: June 2000

Formats: txt json html

Obsoleted by: RFC 3291

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2851

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these definitions will be imported and used in MIBs that would otherwise define their own representations.
This work is output from the Operations and Management Area "IPv6MIB" design team.

RFC 2852 Deliver By SMTP Service Extension

Authors: D. Newman.

Date: June 2000

Formats: txt html json

Updates: RFC 1894

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2852

This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. A client making such a request also specifies the message handling which is to occur if the message cannot be delivered within the specified time period: either the message is to be returned as undeliverable with no further processing, or a "delayed" delivery status notification (DSN) [6] is to be issued.
This extension should not be viewed as a vehicle for requesting"priority" processing. A receiving SMTP server may assign whatever processing priority it wishes to a message transmitted with a DeliverBy request. A Deliver By request serves to express a message's urgency and to provide an additional degree of determinancy in its processing. An indication of an urgent message's status within a given time period may be requested and will be honored. Moreover, the message may be withdrawn if not delivered within that time period.
A typical usage of this mechanism is to prevent delivery of a message beyond some future time of significance to the sender or recipient but not known by the MTAs handling the message. For instance, the sender may know that the message will be delivered as a page but does not consider the message to be sufficiently important as to warrant paging the recipient after business hours. In that case, the message could be marked such that delivery attempts are not made beyond
17:00. Another common usage arises when a sender wishes to be alerted to delivery delays. In this case, the sender can mark a message such that if it is not delivered within, say, 30 minutes, a"delayed" DSN is generated but delivery attempts are nonetheless continued. In this case the sender has been allowed to express a preference for when they would like to learn of delivery problems.

RFC 2853 Generic Security Service API Version 2 : Java Bindings

Authors: J. Kabat, M. Upadhyay.

Date: June 2000

Formats: txt html json

Obsoleted by: RFC 5653

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2853

The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE].
The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are TheSimple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5GSS-API Mechanism [KERBV5].

RFC 2854 The 'text/html' Media Type

Authors: D. Connolly, L. Masinter.

Date: June 2000

Formats: txt json html

Obsoletes: RFC 2070, RFC 1980, RFC 1942, RFC 1867, RFC 1866

Status: INFORMATIONAL

DOI: 10.17487/RFC 2854

This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations; it is intended to obsolete the previous IETF documents defining HTML, including RFC 1866, RFC 1867, RFC 1980, RFC1942 and RFC 2070, and to remove HTML from IETF Standards Track.
This document was prepared at the request of the W3C HTML working group. Please send comments to www-html@w3.org, a public mailing list with archive at <http://lists.w3.org/Archives/Public/www-html/&rt;.

RFC 2855 DHCP for IEEE 1394

Authors: K. Fujisawa.

Date: June 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2855

IEEE Std 1394-1995 is a standard for a High Performance Serial Bus.Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. This memo describes the 1394 specific usage of some fields of DHCP messages.

RFC 2856 Textual Conventions for Additional High Capacity Data Types

Authors: A. Bierman, K. McCloghrie, R. Presuhn.

Date: June 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2856

This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. The definitions contained in this document represent a short term solution which may be deprecated in the future.

RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH

Authors: A. Keromytis, N. Provos.

Date: June 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2857

This memo describes the use of the HMAC algorithm [RFC 2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC EncapsulatingSecurity Payload [ESP] and the revised IPSEC Authentication Header[AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection.
Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].

RFC 2858 Multiprotocol Extensions for BGP-4

Authors: T. Bates, Y. Rekhter, R. Chandra, D. Katz.

Date: June 2000

Formats: txt json html

Obsoletes: RFC 2283

Obsoleted by: RFC 4760

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2858

Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
This document obsoletes RFC 2283.

RFC 2859 A Time Sliding Window Three Colour Marker (TSWTCM)

Authors: W. Fang, N. Seddigh, B. Nandy.

Date: June 2000

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2859

This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner[RFC2475, RFC2474]. The marker is intended to mark packets that will be treated by the Assured Forwarding (AF) Per Hop Behaviour (PHB)[AFPHB] in downstream routers. The TSWTCM meters a traffic stream and marks packets to be either green, yellow or red based on the measured throughput relative to two specified rates: Committed Target Rate(CTR) and Peak Target Rate (PTR).

RFC 2860 Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority

Authors: B. Carpenter, F. Baker, M. Roberts.

Date: June 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2860

This document places on record the text of the Memorandum ofUnderstanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000.

RFC 2861 TCP Congestion Window Validation

Authors: M. Handley, J. Padhye, S. Floyd.

Date: June 2000

Formats: txt json html

Obsoleted by: RFC 7661

Status: HISTORIC

DOI: 10.17487/RFC 2861

TCP's congestion window controls the number of packets a TCP flow may have in the network at any time. However, long periods when the sender is idle or application-limited can lead to the invalidation of the congestion window, in that the congestion window no longer reflects current information about the state of the network. This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window.
An invalid congestion window also results when the congestion window is increased (i.e., in TCP's slow-start or congestion avoidance phases) during application-limited periods, when the previous value of the congestion window might never have been fully utilized. We propose that the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window). We have explored these algorithms both with simulations and with experiments from an implementation in FreeBSD.

RFC 2862 RTP Payload Format for Real-Time Pointers

Authors: M. Civanlar, G. Cash.

Date: June 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2862

This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalities needed to implement a general mouse event transmission mechanism.

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 2864 The Inverted Stack Table Extension to the Interfaces Group MIB

Authors: K. McCloghrie, G. Hanson.

Date: June 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2864

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 which provide an inverted mapping of the interface stack table used for managing network interfaces. [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 2867 RADIUS Accounting Modifications for Tunnel Protocol Support

Authors: G. Zorn, B. Aboba, D. Mitton.

Date: June 2000

Formats: txt html json

Updates: RFC 2866

Status: INFORMATIONAL

DOI: 10.17487/RFC 2867

This document defines new RADIUS accounting Attributes and new values for the existing Acct-Status-Type Attribute [1] designed to support the provision of compulsory tunneling in dial-up networks.

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 2870 Root Name Server Operational Requirements

Authors: R. Bush, D. Karrenberg, M. Kosters, R. Plzak.

Date: June 2000

Formats: txt json html

Obsoletes: RFC 2010

Obsoleted by: RFC 7720

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2870

As the internet becomes increasingly critical to the world's social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details.

RFC 2871 A Framework for Telephony Routing over IP

Authors: J. Rosenberg, H. Schulzrinne.

Date: June 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2871

This document serves as a framework for Telephony Routing over IP(TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony.

RFC 2872 Application and Sub Application Identity Policy Element for Use with RSVP

Authors: Y. Bernet, R. Pabbati.

Date: June 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2872

RSVP [RFC 2205] signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used byRSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information.

RFC 2873 TCP Processing of the IPv4 Precedence Field

Authors: X. Xiao, A. Hannan, V. Paxson, E. Crabbe.

Date: June 2000

Formats: txt html json

Obsoleted by: RFC 9293

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2873

This memo describes a conflict between TCP [RFC793] and DiffServ[RFC2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This memo proposes a modification to TCP for resolving the conflict.
Because the IPv6 [RFC2460] traffic class octet does not have any defined meaning except what is defined in RFC 2474, and in particular does not define precedence or security parameter bits, there is no conflict between TCP and DiffServ on the use of any bits in the IPv6 traffic class octet.

RFC 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 2875 Diffie-Hellman Proof-of-Possession Algorithms

Authors: H. Prafullchandra, J. Schaad.

Date: July 2000

Formats: txt json html

Obsoleted by: RFC 6955

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2875

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of- possession rather than general purpose signing.

RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS

Authors: J. Pawling.

Date: July 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2876

This document describes the conventions for using the Key ExchangeAlgorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types.

RFC 2877 5250 Telnet Enhancements

Authors: T. Murphy Jr., P. Rieth, J. Stevens.

Date: July 2000

Formats: txt html json

Obsoleted by: RFC 4777

Updates: RFC 1205

Status: INFORMATIONAL

DOI: 10.17487/RFC 2877

This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. If a requested device name is not available, a method to retry the request using a new device name is described. Methods to request specific Telnet session settings and auto-signon function are also described.
By allowing a Telnet client to select the device name, the 5250Telnet server opens the door for applications to set and/or extract useful information about the Telnet client. Some possibilities are1) selecting a customized device name associated with a particular user profile name for National Language Support or subsystem routing,2) connecting PC and network printers as clients and 3) auto-signon using clear-text or DES-encrypted password exchange.
Applications may need to use system API's on the AS/400 in order to extract Telnet session settings from the device name description.Refer to the Retrieve Device Description (QDCRDEVD) API described in the AS/400 System API book [3] on how to extract information using the DEVD0600 and DEVD1100 templates.
This memo describes how the IBM 5250 Telnet server supports WorkStation Function (WSF) printers using 5250 Display Station Pass-Through. A response code is returned by the Telnet server to indicate success or failure of the WSF printer session.

RFC 2878 PPP Bridging Control Protocol (BCP)

Authors: M. Higashiyama, F. Baker.

Date: July 2000

Formats: txt json html

Obsoletes: RFC 1638

Obsoleted by: RFC 3518

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2878

The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links.
This document obsoletes RFC 1638, which was based on the IEEE802.1D-1993 MAC Bridge[3]. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1QVirtual LAN (VLAN)[9] standards. This document also improves the protocol in order to support high-speed switched LANs.

RFC 2879 Content Feature Schema for Internet Fax (V2)

Authors: G. Klyne, L. McIntyre.

Date: August 2000

Formats: txt json html

Obsoletes: RFC 2531

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2879

This document defines a content media feature schema for Internet fax.
It is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extendedInternet fax systems [5]. It replaces and updates the feature schema defined in RFC 2531.

RFC 2880 Internet Fax T.30 Feature Mapping

Authors: L. McIntyre, G. Klyne.

Date: August 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2880

This document describes how to map Group 3 fax capability identification bits, described in ITU T.30 [6], into the Internet fax feature schema described in "Content feature schema for Internet fax"[4].
This is a companion to the fax feature schema document [4], which itself defines a profile of the media feature registration mechanisms[1,2,3], for use in performing capability identification between extended Internet fax systems [5].

RFC 2881 Network Access Server Requirements Next Generation (NASREQNG) NAS Model

Authors: D. Mitton, M. Beadles.

Date: July 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2881

This document describes the terminology and gives a model of typicalNetwork Access Server (NAS). The purpose of this effort is to set the reference space for describing and evaluating NAS service protocols, such as RADIUS (RFCs 2865, 2866) [1], [2] and follow-on efforts like AAA Working Group, and the Diameter protocol [3]. These are protocols for carrying user service information for authentication, authorization, accounting, and auditing, between aNetwork Access Server which desires to authenticate its incoming calls and a shared authentication server.

RFC 2882 Network Access Servers Requirements: Extended RADIUS Practices

Authors: D. Mitton.

Date: July 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2882

This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered.
These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment.

RFC 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP

Authors: S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky.

Date: July 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2883

This note defines an extension of the Selective Acknowledgement(SACK) Option [RFC2018] for TCP. RFC 2018 specified the use of theSACK option for acknowledging out-of-sequence data not covered byTCP's cumulative acknowledgement field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgement. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets [BPS99], ACK loss, packet replication, and/or early retransmit timeouts.

RFC 2884 Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks

Authors: J. Hadi Salim, U. Ahmed.

Date: July 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2884

This memo presents a performance study of the Explicit CongestionNotification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. ECN is an end-to-end congestion avoidance mechanism proposed by [6] and incorporated intoRFC 2481[7]. We study the behavior of ECN for both bulk and transactional transfers. Our experiments show that there is improvement in throughput over NON ECN (TCP employing any of Reno,SACK/FACK or NewReno congestion control) in the case of bulk transfers and substantial improvement for transactional transfers.
A more complete pdf version of this document is available at: http://www7.nortel.com:8080/CTL/ecnperf.pdf
This memo in its current revision is missing a lot of the visual representations and experimental results found in the pdf version.

RFC 2885 Megaco Protocol version 0.8

Authors: F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers.

Date: August 2000

Formats: txt json html

Obsoleted by: RFC 3015

Status: HISTORIC

DOI: 10.17487/RFC 2885

This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. A merged document presenting the Megaco protocol with the Errata incorporated will be available shortly.
The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.

RFC 2886 Megaco Errata

Authors: T. Taylor.

Date: August 2000

Formats: txt html json

Obsoleted by: RFC 3015

Status: HISTORIC

DOI: 10.17487/RFC 2886

This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS TRACK]

RFC 2887 The Reliable Multicast Design Space for Bulk Data Transfer

Authors: M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby.

Date: August 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2887

The design space for reliable multicast is rich, with many possible solutions having been devised. However, application requirements serve to constrain this design space to a relatively small solution space. This document provides an overview of the design space and the ways in which application constraints affect possible solutions.

RFC 2888 Secure Remote Access with L2TP

Authors: P. Srisuresh.

Date: August 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2888

L2TP protocol is a virtual extension of PPP across IP network infrastructure. L2TP makes possible for an access concentrator (LAC) to be near remote clients, while allowing PPP termination server(LNS) to be located in enterprise premises. L2TP allows an enterprise to retain control of RADIUS data base, which is used to controlAuthentication, Authorization and Accountability (AAA) of dial-in users. The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This is accomplished without creating new protocols and using the existing practices of Remote Access andIPsec. Specifically, the document proposes three new RADIUS parameters for use by the LNS node, acting as Secure Remote AccessServer (SRAS) to mandate network level security between remote clients and the enterprise. The document also discusses limitations of the approach.

RFC 2889 Benchmarking Methodology for LAN Switching Devices

Authors: R. Mandeville, J. Perser.

Date: August 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2889

This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community.

RFC 2890 Key and Sequence Number Extensions to GRE

Authors: G. Dommety.

Date: September 2000

Formats: txt json html

Updates: RFC 2784

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2890

GRE (Generic Routing Encapsulation) specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GREHeader [1].

RFC 2891 LDAP Control Extension for Server Side Sorting of Search Results

Authors: T. Howes, M. Wahl, A. Anantha.

Date: August 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2891

This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. The controls may be useful when the LDAP client has limited functionality or for some other reason cannot sort the results but still needs them sorted.Other permissible controls on search operations are not defined in this extension.
The sort controls allow a server to return a result code for the sorting of the results that is independent of the result code returned for the search operation.
The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97].

RFC 2892 The Cisco SRP MAC Layer Protocol

Authors: D. Tsiang, G. Suwala.

Date: August 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2892

This document specifies the MAC layer protocol, "Spatial ReuseProtocol" (SRP) for use with ring based media. This is a second version of the protocol (V2).
The primary requirements for SRP are as follows:
- Efficient use of bandwidth using: spatial reuse of bandwidth local reuse of bandwidth minimal protocol overhead- Support for priority traffic- Scalability across a large number of nodes or stations attached to a ring- "Plug and play" design without a software based station management transfer (SMT) protocol or ring master negotiation as seen in other ring based MAC protocols [1][2]- Fairness among nodes using the ring- Support for ring based redundancy (error detection, ring wrap, etc.) similar to that found in SONET BLSR specifications.- Independence of physical layer (layer 1) media type.
This document defines the terminology used with SRP, packet formats, the protocol format, protocol operation and associated protocol finite state machines.

RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers

Authors: R. Gilligan, E. Nordmark.

Date: August 2000

Formats: txt html json

Obsoletes: RFC 1933

Obsoleted by: RFC 4213

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2893

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. This document obsoletes RFC 1933.

RFC 2894 Router Renumbering for IPv6

Authors: M. Crawford.

Date: August 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2894

IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes.
This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of NeighborDiscovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site.

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 2896 Remote Network Monitoring MIB Protocol Identifier Macros

Authors: A. Bierman, C. Bucci, R. Iddon.

Date: August 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2896

This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base)Version 2 [RFC2021] and the RMON Protocol Identifier Reference[RFC2895].
This document contains protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard.It is published to encourage better interoperability between RMON-2 agent implementations, by providing a great deal of RMON related protocol information in one document.
The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion [RFC2895], and an "RMON Protocol Identifier Macros", document (this document) which contains the non-normative portion of that specification.

RFC 2897 Proposal for an MGCP Advanced Audio Package

Authors: D. Cromwell.

Date: August 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2897

This document is a proposal to add a new event/signal package to theMGCP (Media Gateway Control Protocol) protocol to control an ARF(Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server.
This event package provides support for the standard IVR (InteractiveVoice Response) operations of PlayAnnouncement, PlayCollect, andPlayRecord. It supports direct references to simple audio as well as indirect references to simple and complex audio. It provides audio variables, control of audio interruptibility, digit buffer control, special key sequences, and support for reprompting during data collection. It also provides an arbitrary number of user defined qualifiers to be used in resolving complex audio structures. For example, the user could define qualifiers for any or all of the following: language, accent, audio file format, gender, speaker, or customer.

RFC 2898 PKCS #5: Password-Based Cryptography Specification Version 2.0

Authors: B. Kaliski.

Date: September 2000

Formats: txt json html

Obsoleted by: RFC 8018

Status: INFORMATIONAL

DOI: 10.17487/RFC 2898

This memo represents a republication of PKCS #5 v2.0 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification.
This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques.
The recommendations are intended for general application within computer and communications systems, and as such include a fair amount of flexibility. They are particularly intended for the protection of sensitive information such as private keys, as in PKCS#8 [25]. It is expected that application standards and implementation profiles based on these specifications may include additional constraints.
Other cryptographic techniques based on passwords, such as password- based key entity authentication and key establishment protocols[4][5][26] are outside the scope of this document. Guidelines for the selection of passwords are also outside the scope.

RFC 2899 Request for Comments Summary RFC Numbers 2800-2899

Authors: S. Ginoza.

Date: May 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2899

RFC 2900 Internet Official Protocol Standards

Authors: J. Reynolds, R. Braden, S. Ginoza.

Date: August 2001

Formats: txt json html

Obsoletes: RFC 2800

Obsoleted by: RFC 3000

Status: HISTORIC

DOI: 10.17487/RFC 2900

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.

RFC 2901 Guide to Administrative Procedures of the Internet Infrastructure

Authors: Z. Wenzel, J. Klensin, R. Bush, S. Huter.

Date: August 2000

Formats: txt json html

Also: FYI 0037

Status: INFORMATIONAL

DOI: 10.17487/RFC 2901

This document describes the administrative procedures for networks seeking to connect to the global Internet. This includes the steps and operations necessary for address space allocation and registration, routing database registration, and domain name registration. The document also contains information about the required forms and how to obtain them.

RFC 2902 Overview of the 1998 IAB Routing Workshop

Authors: S. Deering, S. Hares, C. Perkins, R. Perlman.

Date: August 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2902

This document is an overview of a Routing workshop held by theInternet Architecture Board (IAB) during March 25-27, 1998. The major points of discussion are listed, along with some conclusions and action items for many of the points of discussion.

RFC 2903 Generic AAA Architecture

Authors: C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence.

Date: August 2000

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2903

This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. A separation of AAA functions required in a multi-domain environment is then proposed using a layered protocol abstraction. The long term goal is to create a generic framework which allows complex authorizations to be realized through a network of interconnected AAA servers.

RFC 2904 AAA Authorization Framework

Authors: J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence.

Date: August 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2904

This memo serves as the base requirements for Authorization ofInternet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols.

RFC 2905 AAA Authorization Application Examples

Authors: J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence.

Date: August 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2905

This memo describes several examples of applications requiring authorization. Each application is described in terms of a consistent framework, and specific authorization requirements of each application are given. This material was not contributed by the working groups responsible for the applications and should not be considered prescriptive for how the applications will meet their authorization needs. Rather the intent is to explore the fundamental needs of a variety of different applications with the view of compiling a set of requirements that an authorization protocol will need to meet in order to be generally useful.

RFC 2906 AAA Authorization Requirements

Authors: S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence.

Date: August 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2906

This document specifies the requirements that AuthenticationAuthorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. The requirements have been elicited from a study of a range of applications including mobile-IP, roamops and others.

RFC 2907 MADCAP Multicast Scope Nesting State Option

Authors: R. Kermode.

Date: September 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2907

This document defines a new option to the Multicast Address DynamicClient Allocation Protocol (MADCAP) to support nested scoping. The new option's purpose is to allow clients to learn which scopes nest inside each other, and hence it may be used for expanding scope searches or hierarchical multicast transport.

RFC 2908 The Internet Multicast Address Allocation Architecture

Authors: D. Thaler, M. Handley, D. Estrin.

Date: September 2000

Formats: txt json html

Obsoleted by: RFC 6308

Status: HISTORIC

DOI: 10.17487/RFC 2908

This document proposes a multicast address allocation architecture(MALLOC) for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server- server coordination mechanism, and an inter-domain mechanism.

RFC 2909 The Multicast Address-Set Claim (MASC) Protocol

Authors: P. Radoslavov, D. Estrin, R. Govindan, M. Handley, S. Kumar, D. Thaler.

Date: September 2000

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 2909

This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. MASC is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. While a domain does not necessarily need to allocate an address set for hosts in that domain to be able to allocate group addresses, allocating an address set to the domain does ensure that inter-domain group- specific distribution trees will be locally-rooted, and that traffic will be sent outside the domain only when and where external receivers exist.

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 2912 Indicating Media Features for MIME Content

Authors: G. Klyne.

Date: September 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2912

In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.
This memo defines a Multipurpose Internet Mail Extensions (MIME)'Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used.

RFC 2913 MIME Content Types in Media Feature Expressions

Authors: G. Klyne.

Date: September 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2913

In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.
This memo defines a media feature tag whose value is a MultipurposeInternet Mail Extensions (MIME) content type. This allows the construction of feature expressions that take account of the MIME content type of the corresponding data.

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 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record

Authors: M. Mealling, R. Daniel.

Date: September 2000

Formats: txt json html

Obsoleted by: RFC 3401, RFC 3402, RFC 3403, RFC 3404

Updates: RFC 2168

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2915

This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label orUniform Resource Identifier (URI). Depending on the value of the flags field of the resource record, the resulting domain label or URI may be used in subsequent queries for the Naming Authority Pointer(NAPTR) resource records (to delegate the name lookup) or as the output of the entire process for which this system is used (a resolution server for URI resolution, a service URI for ENUM style e.164 number to URI mapping, etc).
This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource DiscoverySystems to moving out-of-date services to new domains.
This document updates the portions of RFC 2168 specifically dealing with the definition of the NAPTR records and how other, non-URI specific applications, might use NAPTR.

RFC 2916 E.164 number and DNS

Authors: P. Faltstrom.

Date: September 2000

Formats: txt html json

Obsoleted by: RFC 3761

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2916

This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number.Routing of the actual connection using the service selected using these methods is not discussed.

RFC 2917 A Core MPLS IP VPN Architecture

Authors: K. Muthukrishnan, A. Malis.

Date: September 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2917

This memo presents an approach for building core Virtual PrivateNetwork (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services. The central vision is for the service provider to provide a virtual router service to their customers. The keystones of this architecture are ease of configuration, user security, network security, dynamic neighbor discovery, scaling and the use of existing routing protocols as they exist today without any modifications.

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 2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists

Authors: R. Chandhok, G. Wenger.

Date: March 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2919

Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time.
The List-Id header provides a standard location for such an identifier. In addition, a namespace for list identifiers based on fully qualified domain names is described. This namespace is intended to guarantee uniqueness for list owners who require it, while allowing for a less rigorous namespace for experimental and personal use.
By including the List-Id field, list servers can make it easier for mail clients to provide automated tools for users to perform list functions. The list identifier can serve as a key to make many automated processing tasks easier, and hence more widely available.

RFC 2920 SMTP Service Extension for Command Pipelining

Authors: N. Freed.

Date: September 2000

Formats: txt json html

Obsoletes: RFC 2197

Also: STD 0060

Status: INTERNET STANDARD

DOI: 10.17487/RFC 2920

This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission ControlProtocol (TCP) send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly.

RFC 2921 6BONE pTLA and pNLA Formats (pTLA)

Authors: B. Fink.

Date: September 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2921

This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation",[6BONE-TLA], to create pseudo Top-Level Aggregation Identifiers(pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's).

RFC 2922 Physical Topology MIB

Authors: A. Bierman, K. Jones.

Date: September 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2922

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 physical topology identification and discovery.

RFC 2923 TCP Problems with Path MTU Discovery

Authors: K. Lahey.

Date: September 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2923

This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission UnitDiscovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between MaximumSegment Size (MSS) and segment size, and MSS advertisement based onPMTU.

RFC 2924 Accounting Attributes and Record Formats

Authors: N. Brownlee, A. Blount.

Date: September 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2924

This document summarises Internet Engineering Task Force (IETF) andInternational Telecommunication Union (ITU-T) documents related toAccounting. A classification scheme for the Accounting Attributes in the summarised documents is presented. Exchange formats forAccounting data records are discussed, as are advantages and disadvantages of integrated versus separate record formats and transport protocols. This document discusses service definition independence, extensibility, and versioning. Compound service definition capabilities are described.

RFC 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations

Authors: K. White.

Date: September 2000

Formats: txt json html

Obsoleted by: RFC 4560

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2925

This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to anIP address at a remote host.
Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability.

RFC 2926 Conversion of LDAP Schemas to and from SLP Templates

Authors: J. Kempf, R. Moats, P. St. Pierre.

Date: September 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2926

This document describes a procedure for mapping between ServiceLocation Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. The document covers two aspects of the mapping. One aspect is mapping between SLP service type templates and LDAP directory schema.Because the SLP service type template grammar is relatively simple, mapping from service type templates to LDAP types is straightforward.Mapping in the other direction is straightforward if the attributes are restricted to use just a few of the syntaxes defined in RFC 2252.If arbitrary ASN.1 types occur in the schema, then the mapping is more complex and may even be impossible. The second aspect is representation of service information in an LDAP directory. The recommended representation simplifies interoperability with SLP by allowing SLP directory agents to backend into LDAP directory servers.The resulting system allows service advertisements to propagate easily between SLP and LDAP.

RFC 2927 MIME Directory Profile for LDAP Schema

Authors: M. Wahl.

Date: September 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2927

This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol(LDAP) schema. It is intended for communication with the Internet schema listing service.

RFC 2928 Initial IPv6 Sub-TLA ID Assignments

Authors: R. Hinden, S. Deering, R. Fink, T. Hain.

Date: September 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2928

This document defines initial assignments of IPv6 Sub-Top-LevelAggregation Identifiers (Sub-TLA ID) to the Address Registries. It is intended as technical input to the Internet Assigned NumbersAuthority (IANA) from the Internet Engineering Task Force (IETF)Internet Protocol Next Generation (IPNG) and Next GenerationTransition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses.
This document was originally developed to provide advice to IANA in the fall of 1998 and is being published at this time for the historical record. The Internet Architecture Board (IAB) subsequently requested that the IANA delegate these assignments to the Address Registries. The IANA did this and the Address Registries are now using them to assign IPv6 addresses.

RFC 2929 Domain Name System (DNS) IANA Considerations

Authors: D. Eastlake 3rd, E. Brunner-Williams, B. Manning.

Date: September 2000

Formats: txt json html

Obsoleted by: RFC 5395

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2929

Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System(DNS) classes, Resource Record (RR) types, operation codes, error codes, etc.

RFC 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 2931 DNS Request and Transaction Signatures ( SIG(0)s )

Authors: D. Eastlake 3rd.

Date: September 2000

Formats: txt json html

Updates: RFC 2535

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2931

Extensions to the Domain Name System (DNS) are described in [RFC2535] that can provide data origin and transaction integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures.
Implementation experience has indicated the need for minor but non- interoperable changes in Request and Transaction signature resource records ( SIG(0)s ). These changes are documented herein.

RFC 2932 IPv4 Multicast Routing MIB

Authors: K. McCloghrie, D. Farinacci, D. Thaler.

Date: October 2000

Formats: txt html json

Obsoleted by: RFC 5132

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2932

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing IPMulticast Routing for IPv4, independent of the specific multicast routing protocol in use.

RFC 2933 Internet Group Management Protocol MIB

Authors: K. McCloghrie, D. Farinacci, D. Thaler.

Date: October 2000

Formats: txt html json

Obsoleted by: RFC 5519

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2933

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing the InternetGroup Management Protocol (IGMP).

RFC 2934 Protocol Independent Multicast MIB for IPv4

Authors: K. McCloghrie, D. Farinacci, D. Thaler, B. Fenner.

Date: October 2000

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2934

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 theProtocol Independent Multicast (PIM) protocol for IPv4.

RFC 2935 Internet Open Trading Protocol (IOTP) HTTP Supplement

Authors: D. Eastlake 3rd, C. Smith.

Date: September 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2935

Internet Open Trading Protocol (IOTP) messages will be carried asExtensible Markup Language (XML) documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties.
This document describes that mapping for the Hyper Text TransportProtocol (HTTP), Versions 1.0 and 1.1.

RFC 2936 HTTP MIME Type Handler Detection

Authors: D. Eastlake 3rd, C. Smith, D. Soroka.

Date: September 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2936

Entities composing web pages to provide services over the HypertextTransfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. For example, whether an Internet OpenTrading Protocol (IOTP) or VRML or SET or some streaming media handler is available. In some cases they would want to display different web pages or content depending on a MIME handler's availability. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on theInternet as of early 2000. It is intended to be of practical use to implementors during the period before the wide deployment of superior standards based techniques which may be developed.

RFC 2937 The Name Service Search Option for DHCP

Authors: C. Smith.

Date: September 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2937

This document defines a new Dynamic Host Configuration Protocol(DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information.

RFC 2938 Identifying Composite Media Features

Authors: G. Klyne, L. Masinter.

Date: September 2000

Formats: txt json html

Updates: RFC 2533

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2938

In RFC 2533, an expression format is presented for describing media feature capabilities as a combination of simple media feature tags.
This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite.

RFC 2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types

Authors: R. Droms.

Date: September 2000

Formats: txt json html

Obsoletes: RFC 2489

Also: BCP 0043

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2939

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TransmissionControl Protocol/Internet Protocol (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".
DHCP protocol messages are identified by the 'DHCP Message Type' option (option code 51). Each message type is defined by the data value carried in the 'DHCP Message Type' option.
New DHCP options and message types may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters or to accommodate new protocol semantics. This document describes the procedure for defining new DHCP options and message types.

RFC 2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients

Authors: A. Smith, D. Partain, J. Seligson.

Date: October 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2940

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular it defines objects for managing a client of the CommonOpen Policy Service (COPS) protocol.
This memo includes a MIB module in a manner that is compliant to theSMIv2 [V2SMI].

RFC 2941 Telnet Authentication Option

Authors: T. Ts'o, Ed., J. Altman.

Date: September 2000

Formats: txt html json

Obsoletes: RFC 1416

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2941

This document describes the authentication option to the telnet [1] protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type.
This document updates a previous specification of the telnet authentication option, RFC 1416 [2], so that it can be used to securely enable the telnet encryption option [3].

RFC 2942 Telnet Authentication: Kerberos Version 5

Authors: T. Ts'o.

Date: September 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2942

This document describes how Kerberos Version 5 [1] is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option [2]. This mechanism can also used to provide keying material to provide data confidentiality services in conjunction with the telnet encryption option [3].

RFC 2943 TELNET Authentication Using DSA

Authors: R. Housley, T. Horting, P. Yee.

Date: September 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2943

This document defines a telnet authentication mechanism using theDigital Signature Algorithm (DSA) [FIPS186]. It relies on the TelnetAuthentication Option [RFC2941].

RFC 2944 Telnet Authentication: SRP

Authors: T. Wu.

Date: September 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2944

This document specifies an authentication scheme for the Telnet protocol under the framework described in [RFC2941], using the SecureRemote Password Protocol (SRP) authentication mechanism. The specific mechanism, SRP-SHA1, is described in [RFC2945].

RFC 2945 The SRP Authentication and Key Exchange System

Authors: T. Wu.

Date: September 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2945

This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. This mechanism is suitable for negotiating secure connections using a user-supplied password, while eliminating the security problems traditionally associated with reusable passwords.This system also performs a secure key exchange in the process of authentication, allowing security layers (privacy and/or integrity protection) to be enabled during the session. Trusted key servers and certificate infrastructures are not required, and clients are not required to store or manage any long-term keys. SRP offers both security and deployment advantages over existing challenge-response techniques, making it an ideal drop-in replacement where secure password authentication is needed.

RFC 2946 Telnet Data Encryption Option

Authors: T. Ts'o.

Date: September 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2946

This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. While this document summarizes currently utilized encryption types and codes, it does not define a specific encryption algorithm.Separate documents are to be published defining implementations of this option for each encryption algorithm.

RFC 2947 Telnet Encryption: DES3 64 bit Cipher Feedback

Authors: J. Altman.

Date: September 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2947

This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option.

RFC 2948 Telnet Encryption: DES3 64 bit Output Feedback

Authors: J. Altman.

Date: September 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2948

This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option.

RFC 2949 Telnet Encryption: CAST-128 64 bit Output Feedback

Authors: J. Altman.

Date: September 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2949

This document specifies how to use the CAST-128 encryption algorithm in output feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit.

RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback

Authors: J. Altman.

Date: September 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2950

This document specifies how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit.

RFC 2951 TELNET Authentication Using KEA and SKIPJACK

Authors: R. Housley, T. Horting, P. Yee.

Date: September 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2951

This document defines a method to authenticate TELNET using the KeyExchange Algorithm (KEA), and encryption of the TELNET stream usingSKIPJACK. Two encryption modes are specified; one provides data integrity and the other does not. The method relies on the TELNETAuthentication Option.

RFC 2952 Telnet Encryption: DES 64 bit Cipher Feedback

Authors: T. Ts'o.

Date: September 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2952

This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option.

RFC 2953 Telnet Encryption: DES 64 bit Output Feedback

Authors: T. Ts'o.

Date: September 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2953

This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option.

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 2956 Overview of 1999 IAB Network Layer Workshop

Authors: M. Kaat.

Date: October 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2956

This document is an overview of a workshop held by the InternetArchitecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet.Different technical scenarios for the (foreseeable) future and the impact of external influences were studied. This report lists the conclusions and recommendations to the Internet Engineering TaskForce (IETF) community.

RFC 2957 The application/whoispp-query Content-Type

Authors: L. Daigle, P. Faltstrom.

Date: October 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2957

This document defines the expression of Whois++ protocol (RFC 1835) queries within MIME (Multipurpose Internet Mail Extensions) (RFC2046) media types. The intention of this document, in conjunction with RFC 2958 is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions.

RFC 2958 The application/whoispp-response Content-type

Authors: L. Daigle, P. Faltstrom.

Date: October 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2958

This document defines the expression of Whois++ protocol (RFC1835) responses within MIME (Multipurpose Internet Mail Extensions)(RFC2046) media types. The intention of this document, in conjunction with RFC 2957 is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions.

RFC 2959 Real-Time Transport Protocol Management Information Base

Authors: M. Baugher, B. Strahm, I. Suconick.

Date: October 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2959

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing Real-Time TransportProtocol (RTP) systems (RFC1889).

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 2962 An SNMP Application Level Gateway for Payload Address Translation

Authors: D. Raz, J. Schoenwaelder, B. Sugla.

Date: October 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2962

This document describes the ALG (Application Level Gateway) for theSNMP (Simple Network Management Protocol) by which IP (InternetProtocol) addresses in the payload of SNMP packets are statically mapped from one group to another. The SNMP ALG is a specific case of an Application Level Gateway as described in [15].
An SNMP ALG allows network management stations to manage multiple networks that use conflicting IP addresses. This can be important in environments where there is a need to use SNMP with NAT (NetworkAddress Translator) in order to manage several potentially overlapping addressing realms.
This document includes a detailed description of the requirements and limitations for an implementation of an SNMP Application LevelGateway. It also discusses other approaches to exchange SNMP packets across conflicting addressing realms.

RFC 2963 A Rate Adaptive Shaper for Differentiated Services

Authors: O. Bonaventure, S. De Cnodder.

Date: October 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2963

This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 andRFC2698, respectively. These RAS improve the performance of TCP when a TCM is used at the ingress of a diffserv network by reducing the burstiness of the traffic. With TCP traffic, this reduction of the burstiness is accompanied by a reduction of the number of marked packets and by an improved TCP goodput. The proposed RAS can be used at the ingress of Diffserv networks providing the Assured ForwardingPer Hop Behavior (AF PHB). They are especially useful when a TCM is used to mark traffic composed of a small number of TCP connections.

RFC 2964 Use of HTTP State Management

Authors: K. Moore, N. Freed.

Date: October 2000

Formats: txt html json

Also: BCP 0044

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2964

The mechanisms described in "HTTP State Management Mechanism" (RFC-2965), and its predecessor (RFC-2109), can be used for many different purposes. However, some current and potential uses of the protocol are controversial because they have significant user privacy and security implications. This memo identifies specific uses ofHypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification.

RFC 2965 HTTP State Management Mechanism

Authors: D. Kristol, L. Montulli.

Date: October 2000

Formats: txt html json

Obsoletes: RFC 2109

Obsoleted by: RFC 6265

Status: HISTORIC

DOI: 10.17487/RFC 2965

This document specifies a way to create a stateful session withHypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)
This document reflects implementation experience with RFC 2109 and obsoletes it.

RFC 2966 Domain-wide Prefix Distribution with Two-Level IS-IS

Authors: T. Li, T. Przygienda, H. Smit.

Date: October 2000

Formats: txt json html

Obsoleted by: RFC 5302

Status: INFORMATIONAL

DOI: 10.17487/RFC 2966

This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195 [2].
This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 IntermediateSystems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form.The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain.

RFC 2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways

Authors: L. Daigle, R. Hedberg.

Date: October 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2967

The strength of the TISDAG (Technical Infrastructure for SwedishDirectory Access Gateways) project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access- point service for information on Swedish Internet users. The resulting service will provide uniform access for all information -- the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end-user's client access protocol.

RFC 2968 Mesh of Multiple DAG servers - Results from TISDAG

Authors: L. Daigle, T. Eklof.

Date: October 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2968

The Common Indexing Protocol ([CIP1]) is designed to facilitate the creation not only of query referral indexes, but also of meshes of(loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG(Technical Infrastructure for Swedish Directory Access Gateways) project ([TISDAG], [DAGEXP]) has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services.

RFC 2969 Wide Area Directory Deployment - Experiences from TISDAG

Authors: T. Eklof, L. Daigle.

Date: October 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2969

The TISDAG (Technical Infrastructure for Swedish Directory AccessGateway) project provided valuable insight into the current reality of deploying a wide-scale directory service. This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. A perspective on the project's relationship to other directory deployment projects is provided, along with some proposals for future extensions of the work(larger scale deployment, other application areas).
These are our own observations, based on work done and general project discussions. No doubt, other project participants have their own list of project experiences; we don't claim this document is exhaustive!

RFC 2970 Architecture for Integrated Directory Services - Result from TISDAG

Authors: L. Daigle, T. Eklof.

Date: October 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2970

A single, unified, global whitepages directory service remains elusive. Nonetheless, there is increasing call for participation of widely-dispersed directory servers (i.e., across multiple organizations) in large-scale directory services. These services range from national whitepages services, to multi-national indexes ofWWW resources, and beyond. Drawing from experiences with the TISDAG(Technical Infrastructure for Swedish Directory Access Gateways)([TISDAG]) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use.

RFC 2971 IMAP4 ID extension

Authors: T. Showalter.

Date: October 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2971

The ID extension to the Internet Message Access Protocol - Version4rev1 (IMAP4rev1) protocol allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete.

RFC 2972 Context and Goals for Common Name Resolution

Authors: N. Popp, M. Mealling, L. Masinter, K. Sollins.

Date: October 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2972

This document establishes the context and goals for a Common NameResolution Protocol. It defines the terminology used concerning a"Common Name" and how one might be "resolved", and establishes the distinction between "resolution" and more elaborate search mechanisms. It establishes some expected contexts for use of CommonName Resolution, and the criteria for evaluating a successful protocol. It also analyzes the various motivations that would cause services to provide Common Name resolution for both public, private and commercial use.
This document is intended as input to the formation of a Common NameResolution Protocol working group. Please send any comments to cnrp-ietf@lists.internic.net. To review the mail archives, see<http://lists.internic.net/archives/cnrp-ietf.html&rt;

RFC 2973 IS-IS Mesh Groups

Authors: R. Balay, D. Katz, J. Parker.

Date: October 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2973

This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System(IS-IS) Routing protocol, as described in ISO 10589. The described mechanism can be used to reduce the flooding of Link State PDUs(Protocol Data Units) (LSPs) in IS-IS topologies. The net effect is to engineer a flooding topology for LSPs which is a subset of the physical topology. This document serves to document the existing behavior in deployed implementations.
The document describes behaviors that are backwards compatible with implementations that do not support this feature.

RFC 2974 Session Announcement Protocol

Authors: M. Handley, C. Perkins, E. Whelan.

Date: October 2000

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 2974

This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.

RFC 2975 Introduction to Accounting Management

Authors: B. Aboba, J. Arkko, D. Harrington.

Date: October 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2975

The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document describes each of these problems, and discusses the issues involved in design of modern accounting systems.
Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Thus the goal of accounting management is to provide a set of tools that can be used to meet the requirements of each application.This document describes the currently available tools as well as the state of the art in accounting protocol design. A companion document, RFC 2924, reviews the state of the art in accounting attributes and record formats.

RFC 2976 The SIP INFO Method

Authors: S. Donovan.

Date: October 2000

Formats: txt json html

Obsoleted by: RFC 6086

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2976

This document proposes an extension to the Session InitiationProtocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP andISDN signaling messages used to control telephony call services.
This and other example uses of the INFO method may be standardized in the future.

RFC 2977 Mobile IP Authentication, Authorization, and Accounting Requirements

Authors: S. Glass, T. Hiller, S. Jacobs, C. Perkins.

Date: October 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2977

The Mobile IP and Authentication, Authorization, Accounting (AAA) working groups are currently looking at defining the requirements forAuthentication, Authorization, and Accounting. This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services.

RFC 2978 IANA Charset Registration Procedures

Authors: N. Freed, J. Postel.

Date: October 2000

Formats: txt html json

Obsoletes: RFC 2278

Also: BCP 0019

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 2978

Multipurpose Internet Mail Extensions (MIME) (RFC-2045, RFC-2046,RFC-2047, RFC-2184) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential.
Note: The charset registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects.In particular, the general applicability and appropriateness of a given registered charset to a particular application is a protocol issue, not a registration issue, and is not dealt with by this registration procedure.

RFC 2979 Behavior of and Requirements for Internet Firewalls

Authors: N. Freed.

Date: October 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2979

This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. While most of these things may seem obvious, current firewall behavior is often either unspecified or underspecified and this lack of specificity often causes problems in practice. This requirement is intended to be a necessary first step in making the behavior of firewalls more consistent across implementations and in line with accepted IP protocol practices.

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 2981 Event MIB

Authors: R. Kavasseri, Ed..

Date: October 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2981

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 that can be used to manage and monitor MIB objects and take action through events.
The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met.

RFC 2982 Distributed Management Expression MIB

Authors: R. Kavasseri, Ed..

Date: October 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2982

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 expressions of MIB objects. The results of these expressions becomeMIB objects usable like any other MIB object, such as for the test condition for declaring an event.

RFC 2983 Differentiated Services and Tunnels

Authors: D. Black.

Date: October 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2983

This document considers the interaction of Differentiated Services(diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms.The discussion of tunnels in the diffserv architecture (RFC 2475) provides insufficient guidance to tunnel designers and implementers.This document describes two conceptual models for the interaction of diffserv with Internet Protocol (IP) tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPSec tunnels limit the possible functionality in some circumstances.

RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS

Authors: C. Adams.

Date: October 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2984

This document specifies how to incorporate CAST-128 (RFC2144) into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. The relevant OIDs and processing steps are provided so that CAST-128 may be included in the CMS specification (RFC2630) for symmetric content and key encryption.

RFC 2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0

Authors: M. Nystrom, B. Kaliski.

Date: November 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2985

This memo represents a republication of PKCS #9 v2.0 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification.
This memo provides a selection of object classes and attribute types for use in conjunction with public-key cryptography and LightweightDirectory Access Protocol (LDAP) accessible directories. It also includes ASN.1 syntax for all constructs.

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 2987 Registration of Charset and Languages Media Features Tags

Authors: P. Hoffman.

Date: November 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2987

This document contains the registration for two media feature tags:"charset" and "language". These media features allow specification of character sets and human languages that can be understood by devices and the devices' users. The templates in this document are derived from RFC 2506.

RFC 2988 Computing TCP's Retransmission Timer

Authors: V. Paxson, M. Allman.

Date: November 2000

Formats: txt html json

Obsoleted by: RFC 6298

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2988

This document defines the standard algorithm that TransmissionControl Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.

RFC 2989 Criteria for Evaluating AAA Protocols for Network Access

Authors: B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, P. Walsh, G. Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim, B. Hirschman, R. Hsu, H. Koo, M. Lipford, E. Campbell, Y. Xu, S. Baba, E. Jaques.

Date: November 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2989

This document represents a summary of Authentication, Authorization,Accounting (AAA) protocol requirements for network access. In creating this document, inputs were taken from documents produced by the Network Access Server Requirements Next Generation (NASREQ),Roaming Operations (ROAMOPS), and MOBILEIP working groups, as well as from TIA 45.6.
This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents.

RFC 2990 Next Steps for the IP QoS Architecture

Authors: G. Huston.

Date: November 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2990

While there has been significant progress in the definition ofQuality of Service (QoS) architectures for internet networks, there are a number of aspects of QoS that appear to need further elaboration as they relate to translating a set of tools into a coherent platform for end-to-end service delivery. This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets.
This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.

RFC 2991 Multipath Issues in Unicast and Multicast Next-Hop Selection

Authors: D. Thaler, C. Hopps.

Date: November 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2991

Various routing protocols, including Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (ISIS), explicitly allow "Equal-Cost Multipath" (ECMP) routing. Some router implementations also allow equal-cost multipath usage with RIP and other routing protocols. The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next- hop should be used for a given data packet.

RFC 2992 Analysis of an Equal-Cost Multi-Path Algorithm

Authors: C. Hopps.

Date: November 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2992

Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops.

RFC 2993 Architectural Implications of NAT

Authors: T. Hain.

Date: November 2000

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 2993

In light of the growing interest in, and deployment of network address translation (NAT) RFC-1631, this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in RFC-1631.

RFC 2994 A Description of the MISTY1 Encryption Algorithm

Authors: H. Ohta, M. Matsui.

Date: November 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2994

This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part.

RFC 2995 Pre-Spirits Implementations of PSTN-initiated Services

Authors: H. Lu, Ed., I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum, L. Robart.

Date: November 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2995

This document contains information relevant to the work underway inThe Services in the PSTN/IN Requesting InTernet Services (SPIRITS)Working Group. It describes four existing implementations ofSPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.
Surveying the implementations, we can make the following observations: o The ICW service plays the role of a benchmark service. All four implementations can support ICW, with three specifically designed for it. o Session Initiation Protocol (SIP) is used in most of the implementations as the base communications protocol between thePSTN and Internet. (NEC's implementation is the only exception that uses a proprietary protocol. Nevertheless, NEC has a plan to support SIP together with the extensions for SPIRITS services.) o All implementations use IN-based solutions for the PSTN part.
It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementations inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS WorkingGroup to define the inter-networking interfaces that will support interoperation of the future implementations of SPIRITS services.

RFC 2996 Format of the RSVP DCLASS Object

Authors: Y. Bernet.

Date: November 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2996

Resource Reservation Protocol (RSVP) signaling may be used to requestQuality of Service (QoS) services and enhance the manageability of application traffic's QoS in a differentiated service (diff-serv orDS) network. When using RSVP with DS networks it is useful to be able to carry carry Differentiated Services Code Points (DSCPs) inRSVP message objects. One example of this is the use of RSVP to arrange for the marking of packets with a particular DSCP upstream from the DS network's ingress point, at the sender or at a previous network's egress router.
The DCLASS object is used to represent and carry DSCPs within RSVP messages. This document specifies the format of the DCLASS object and briefly discusses its use.

RFC 2997 Specification of the Null Service Type

Authors: Y. Bernet, A. Smith, B. Davie.

Date: November 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 2997

In the typical Resource Reservation Protocol (RSVP)/Intserv model, applications request a specific Intserv service type and quantify the resources required for that service. For certain applications, the determination of service parameters is best left to the discretion of the network administrator. For example, ERP applications are often mission critical and require some form of prioritized service, but cannot readily specify their resource requirements. To serve such applications, we introduce the notion of the 'Null Service'. TheNull Service allows applications to identify themselves to networkQuality of Service (QoS) policy agents, using RSVP signaling.However, it does not require them to specify resource requirements.QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling [intdiff]. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service.

RFC 2998 A Framework for Integrated Services Operation over Diffserv Networks

Authors: Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine.

Date: November 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2998

The Integrated Services (Intserv) architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks. To support this end-to-end model, theIntserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path. This document describes a framework by which Integrated Services may be supported over Diffserv networks.

RFC 2999 Request for Comments Summary RFC Numbers 2900-2999

Authors: S. Ginoza.

Date: August 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 2999

RFC 3000 Internet Official Protocol Standards

Authors: J. Reynolds, R. Braden, S. Ginoza, L. Shiota.

Date: November 2001

Formats: txt json html

Obsoletes: RFC 2900

Obsoleted by: RFC 3300

Status: HISTORIC

DOI: 10.17487/RFC 3000

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.

RFC 3001 A URN Namespace of Object Identifiers

Authors: M. Mealling.

Date: November 2000

Formats: txt json html

Obsoleted by: RFC 3061

Status: INFORMATIONAL

DOI: 10.17487/RFC 3001

This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs).

RFC 3002 Overview of 2000 IAB Wireless Internetworking Workshop

Authors: D. Mitzel.

Date: December 2000

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3002

This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on wireless internetworking. The workshop was hosted by Nokia in Mountain View, CA, USA on February 29 thruMarch 2, 2000. The goal of the workshop was to assess current and future uses of Internet technology in wireless environments, to make recommendations on research and standardization tasks to improve acceptance of Internet network and transport protocols in wireless environments, and to evaluate methods to improve communication and collaboration among Internet standards working groups and those of the telephony and wireless sectors. This report summarizes the conclusions and recommendations of the IAB on behalf of the IETF community.
Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mailing list.

RFC 3003 The audio/mpeg Media Type

Authors: M. Nilsson.

Date: November 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3003

The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose InternetMail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents.

RFC 3004 The User Class Option for DHCP

Authors: G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat.

Date: November 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3004

This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user.

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 3006 Integrated Services in the Presence of Compressible Flows

Authors: B. Davie, C. Iturralde, D. Oran, S. Casner, J. Wroclawski.

Date: November 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3006

An Integrated Services (int-serv) router performs admission control and resource allocation based on the information contained in a TSpec(among other things). As currently defined, TSpecs convey information about the data rate (using a token bucket) and range of packet sizes of the flow in question. However, the TSpec may not be an accurate representation of the resources needed to support the reservation if the router is able to compress the data at the link level. This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. Routers which support appropriate compression take advantage of the hint in their admission control decisions and resource allocation procedures; other routers ignore the hint. An initial application of this approach is to notify routers performing real-time transport protocol(RTP) header compression that they may allocate fewer resources toRTP flows.

RFC 3007 Secure Domain Name System (DNS) Dynamic Update

Authors: B. Wellington.

Date: November 2000

Formats: txt html json

Obsoletes: RFC 2137

Updates: RFC 2535, RFC 2136

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3007

This document proposes a method for performing secure Domain NameSystem (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization.

RFC 3008 Domain Name System Security (DNSSEC) Signing Authority

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 3009 Registration of parityfec MIME types

Authors: J. Rosenberg, H. Schulzrinne.

Date: November 2000

Formats: txt json html

Obsoleted by: RFC 5109

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3009

The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes.This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats.

RFC 3010 NFS version 4 Protocol

Authors: S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck.

Date: December 2000

Formats: txt json html

Obsoleted by: RFC 3530

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3010

NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

RFC 3011 The IPv4 Subnet Selection Option for DHCP

Authors: G. Waters.

Date: November 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3011

This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address.This option would override a DHCP server's normal methods of selecting the subnet on which to allocate an address for a client.

RFC 3012 Mobile IPv4 Challenge/Response Extensions

Authors: C. Perkins, P. Calhoun.

Date: November 2000

Formats: txt html json

Obsoleted by: RFC 4721

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3012

Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent.Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.

RFC 3013 Recommended Internet Service Provider Security Services and Procedures

Authors: T. Killalea.

Date: November 2000

Formats: txt html json

Also: BCP 0046

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3013

The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet ServiceProviders (ISPs) with respect to security.
It is not the intent of this document to define a set of requirements that would be appropriate for all ISPs, but rather to raise awareness among ISPs of the community's expectations, and to provide the community with a framework for discussion of security expectations with current and prospective service providers.

RFC 3014 Notification Log MIB

Authors: R. Kavasseri.

Date: November 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3014

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 logging SimpleNetwork Management Protocol (SNMP) Notifications.

RFC 3015 Megaco Protocol Version 1.0

Authors: F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers.

Date: November 2000

Formats: txt json html

Obsoletes: RFC 2885, RFC 2886

Obsoleted by: RFC 3525

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3015

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and aMedia Gateway Controller. The document is common text with ITU-TRecommendation H.248 and is a result of applying the changes in RFC2886 to the text of RFC 2885.
The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.

RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams

Authors: Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata.

Date: November 2000

Formats: txt html json

Obsoleted by: RFC 6416

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3016

This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications forMultipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP).

RFC 3017 XML DTD for Roaming Access Phone Book

Authors: M. Riegel, G. Zorn.

Date: December 2000

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3017

This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. It comprises the information necessary to select the most appropriate ISP and to configure the host to get access to the network of the provider. The specification consists of a small set of required information elements and a variety of possible extensions.All data is specified in XML [5] (Extensible Markup Language) syntax leading to a concise XML DTD (Document Type Declaration) for the phone book.

RFC 3018 Unified Memory Space Protocol Specification

Authors: A. Bogdanov.

Date: December 2000

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3018

This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes.

RFC 3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol

Authors: B. Haberman, R. Worzella.

Date: January 2001

Formats: txt json html

Obsoleted by: RFC 5519

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3019

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in Internet ProtocolVersion 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the MulticastListener Discovery Protocol [RFC2710].

RFC 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 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links

Authors: A. Retana, R. White, V. Fuller, D. McPherson.

Date: December 2000

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3021

With ever-increasing pressure to conserve IP address space on theInternet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout theInternet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way.

RFC 3022 Traditional IP Network Address Translator (Traditional NAT)

Authors: P. Srisuresh, K. Egevang.

Date: January 2001

Formats: txt html json

Obsoletes: RFC 1631

Status: INFORMATIONAL

DOI: 10.17487/RFC 3022

Basic Network Address Translation or Basic NAT is a method by whichIP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation, or NAPT is a method by which many network addresses and their TCP/UDP (Transmission ControlProtocol/User Datagram Protocol) ports are translated into a single network address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a realm with private addresses to an external realm with globally unique registered addresses.

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 3024 Reverse Tunneling for Mobile IP, revised

Authors: G. Montenegro, Ed..

Date: January 2001

Formats: txt json html

Obsoletes: RFC 2344

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3024

Mobile Internet Protocol (IP) uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent.
This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address.
This document obsoletes RFC 2344.

RFC 3025 Mobile IP Vendor/Organization-Specific Extensions

Authors: G. Dommety, K. Leung.

Date: February 2001

Formats: txt json html

Obsoleted by: RFC 3115

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3025

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes.

RFC 3026 Liaison to IETF/ISOC on ENUM

Authors: R. Blane.

Date: January 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3026

Working Party 1/2, of the International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. The agenda of the meeting contained several contributions regarding RFC 2916:"E.164 Number and DNS" from the Internet Engineering Task Force's(IETF) ENUM Working Group - more specifically, the method for administering and maintaining the E.164-based resources in the DomainName System (DNS) as related to the ENUM protocol. Consequently, in addition to the WP1/2 collaborators, there were several members of the IETF present to assist with the discussion of issues contained in the aforementioned contributions.
This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions.

RFC 3027 Protocol Complications with the IP Network Address Translator

Authors: M. Holdrege, P. Srisuresh.

Date: January 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3027

Many internet applications can be adversely affected when end nodes are not in the same address realm and seek the assistance of an IPNetwork Address Translator (NAT) enroute to bridge the realms. TheNAT device alone cannot provide the necessary application/protocol transparency in all cases and seeks the assistance of ApplicationLevel Gateways (ALGs) where possible, to provide transparency. The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. It is not possible to capture all applications that break with NAT in a single document. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. We hope the coverage provides sufficient clues for applications not covered.

RFC 3028 Sieve: A Mail Filtering Language

Authors: T. Showalter.

Date: January 2001

Formats: txt json html

Obsoleted by: RFC 5228, RFC 5429

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3028

This document describes a language for filtering e-mail messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black boxInternet Message Access Protocol (IMAP) servers, as it has no variables, loops, or ability to shell out to external programs.

RFC 3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols

Authors: C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato.

Date: February 2001

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3029

This document describes a general Data Validation and CertificationServer (DVCS) and the protocols to be used when communicating with it. The Data Validation and Certification Server is a Trusted ThirdParty (TTP) that can be used as one component in building reliable non-repudiation services.
Useful Data Validation and Certification Server responsibilities in aPKI are to assert the validity of signed documents, public key certificates, and the possession or existence of data.
Assertions created by this protocol are called Data ValidationCertificates (DVC).
We give examples of how to use the Data Validation and CertificationServer to extend the lifetime of a signature beyond key expiry or revocation and to query the Data Validation and Certification Server regarding the status of a public key certificate. The document includes a complete example of a time stamping transaction.

RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages

Authors: G. Vaudreuil.

Date: December 2000

Formats: txt json html

Obsoletes: RFC 1830

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3030

This memo defines two extensions to the SMTP (Simple Mail TransferProtocol) service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called "BDAT", for efficiently sending large MIME (MultipurposeInternet Mail Extensions) messages. The second extension takes advantage of the BDAT command to permit the negotiated sending ofMIME messages that employ the binary transfer encoding. This document is intended to update and obsolete RFC 1830.

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 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol

Authors: M. Suzuki.

Date: January 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3033

The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 GenericIdentifier and Q.2957 User-to-user Signaling for the Internet protocol.
The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS- sensitive session transfers over ATM.

RFC 3034 Use of Label Switching on Frame Relay Networks Specification

Authors: A. Conta, P. Doolan, A. Malis.

Date: January 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3034

This document defines the model and generic mechanisms forMultiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol LabelSwitching Architecture described in [ARCH] and the Label DistributionProtocol (LDP) described in [LDP] relative to Frame Relay Networks.MPLS enables the use of Frame Relay Switches as Label SwitchingRouters (LSRs).

RFC 3035 MPLS using LDP and ATM VC Switching

Authors: B. Davie, J. Lawrence, K. McCloghrie, E. Rosen, G. Swallow, Y. Rekhter, P. Doolan.

Date: January 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3035

The Multiprotocol Label Switching (MPLS) Architecture [1] discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used asLabel Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), IntermediateSystem to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. NoATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers).
This document extends and clarifies the relevant portions of [1] and[2] by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels representForwarding Equivalence Classes (FECs, see [1]) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms.
This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3].

RFC 3036 LDP Specification

Authors: L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas.

Date: January 2001

Formats: txt html json

Obsoleted by: RFC 5036

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3036

The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that twoLabel Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.

RFC 3037 LDP Applicability

Authors: B. Thomas, E. Gray.

Date: January 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3037

Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet nexthops. A fundamental concept in MPLS is that two Label 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 describes the applicability of 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 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 3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile

Authors: S. Santesson, W. Polk, P. Barzin, M. Nystrom.

Date: January 2001

Formats: txt json html

Obsoleted by: RFC 3739

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3039

This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The term QualifiedCertificate is used to describe a certificate with a certain qualified status within applicable governing law. Further, QualifiedCertificates are issued exclusively to physical persons.
The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs.
It is important to note that the profile does not define any legal requirements for Qualified Certificates.

RFC 3040 Internet Web Replication and Caching Taxonomy

Authors: I. Cooper, I. Melve, G. Tomlinson.

Date: January 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3040

This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. Currently deployed solutions employing these technologies are presented to establish a standard taxonomy. Known problems with caching proxies are covered in the document titled"Known HTTP Proxy/Caching Problems", and are not part of this document. This document presents open protocols and points to published material for each protocol.

RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6

Authors: T. Narten, R. Draves.

Date: January 2001

Formats: txt html json

Obsoleted by: RFC 4941

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3041

Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host ConfigurationProtocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.

RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit

Authors: M. Allman, H. Balakrishnan, S. Floyd.

Date: January 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3042

This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. The"Limited Transmit" algorithm calls for sending a new data segment in response to each of the first two duplicate acknowledgments that arrive at the sender. Transmitting these segments increases the probability that TCP can recover from a single lost segment using the fast retransmit algorithm, rather than using a costly retransmission timeout. Limited Transmit can be used both in conjunction with, and in the absence of, the TCP selective acknowledgment (SACK) mechanism.

RFC 3043 The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations

Authors: M. Mealling.

Date: January 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3043

This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations.

RFC 3044 Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace

Authors: S. Rozenfeld.

Date: January 2001

Formats: txt html json

Obsoleted by: RFC 8254

Status: HISTORIC

DOI: 10.17487/RFC 3044

This document presents how the ISSN - International Standard SerialNumber - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier.
An ISSN URN resolution system using the ISSN identifier as Uniform resource Name within an ISN URN Namespace has been developed by theISSN International Centre (ISSN-IC) and is operating as a demonstrator to evaluate all requirements to deploy it in an operational environment.
This proceeds from concepts and proposals developed in several IETFRFCs emphasising the way to implement and to use "recognised" existing numbering system within the URN framework (RFC 2248, RFC2141, RFC 2611).

RFC 3045 Storing Vendor Information in the LDAP root DSE

Authors: M. Meredith.

Date: January 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3045

This document specifies two Lightweight Directory Access Protocol(LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. These two attributes supplement the attributes defined in section 3.4 of RFC 2251.
The information held in these attributes MAY be used for display and informational purposes and MUST NOT be used for feature advertisement or discovery.

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 3047 RTP Payload Format for ITU-T Recommendation G.722.1

Authors: P. Luthi.

Date: January 2001

Formats: txt json html

Obsoleted by: RFC 5577

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3047

International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec, which operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use ofG.722.1 with MIME and SDP.

RFC 3048 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer

Authors: B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, M. Luby.

Date: January 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3048

This document describes a framework for the standardization of bulk- data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalities between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as "building blocks". The remaining parts of the protocols, consisting of highly protocol specific, tightly intertwined functions, shall be designated as "protocol cores".Thus, each protocol can then be constructed by merging a "protocol core" with a number of "building blocks" which can be re-used across multiple protocols.

RFC 3049 TN3270E Service Location and Session Balancing

Authors: J. Naugle, K. Kasthurirangan, G. Ledford.

Date: January 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3049

This document discusses the implementation of Service LocationProtocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server.
Application program developer's can locate TN3270E services and load balance among those services (3270 host sessions), by using this SLP support.

RFC 3050 Common Gateway Interface for SIP

Authors: J. Lennox, H. Schulzrinne, J. Rosenberg.

Date: January 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3050

In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the CommonGateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between theSession Initiation Protocol (SIP) and the Hyper Text TransferProtocol (HTTP), CGI is a good candidate for service creation in aSIP environment. This document defines a SIP CGI interface for providing SIP services on a SIP server.

RFC 3051 IP Payload Compression Using ITU-T V.44 Packet Method

Authors: J. Heath, J. Border.

Date: January 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3051

This document describes a compression method based on the data compression algorithm described in International TelecommunicationUnion (ITU-T) Recommendation V.44. Recommendation V.44 is a modem standard but Annex B, Clause B.1, of the recommendation describes the implementation of V.44 in packet networks (e.g., V.44 Packet Method).This document defines the application of V.44 Packet Method to theInternet Protocol (IP) Payload Compression Protocol (RFC 2393). RFC2393 defines a method for applying lossless compression to the payload portion of IP datagrams.
V.44 Packet Method is based upon the LZJH data compression algorithm.Throughout the remainder of this document the terms V.44 PacketMethod and LZJH are synonymous.

RFC 3052 Service Management Architectures Issues and Review

Authors: M. Eder, S. Nag.

Date: January 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3052

Many of the support functions necessary to exploit the mechanisms by which differing levels of service can be provided are limited in scope and a complete framework is non-existent. Various efforts at such a framework have received a great deal of attention and represent a historical shift in scope for many of the organizations looking to address this problem. The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved.

RFC 3053 IPv6 Tunnel Broker

Authors: A. Durand, P. Fasano, I. Guardini, D. Lento.

Date: January 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3053

The IPv6 global Internet as of today uses a lot of tunnels over the existing IPv4 infrastructure. Those tunnels are difficult to configure and maintain in a large scale environment. The 6bone has proven that large sites and Internet Service Providers (ISPs) can do it, but this process is too complex for the isolated end user who already has an IPv4 connection and would like to enter the IPv6 world. The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network(e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented atOrlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting inFebruary 1999.

RFC 3054 Megaco IP Phone Media Gateway Application Profile

Authors: P. Blatherwick, R. Bell, P. Holland.

Date: January 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3054

This document specifies a particular application of the Megaco/H.248Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. The telephone itself is a MediaGateway (MG), controlled by the Megaco/H.248 Protocol, with application control intelligence located in the Media GatewayController (MGC). To achieve a high degree of interoperability and design efficiency in such end-user devices, a consistent architectural approach, a particular organization of Terminations andPackages, and a Protocol Profile are described. The approach makes use of existing Protocol features and user interface relatedPackages, and is thus a straight-forward application of theMegaco/H.248 Protocol.

RFC 3055 Management Information Base for the PINT Services Architecture

Authors: M. Krishnaswamy, D. Romascanu.

Date: February 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3055

This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture.

RFC 3056 Connection of IPv6 Domains via IPv4 Clouds

Authors: B. Carpenter, K. Moore.

Date: February 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3056

This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence ofIPv4 and IPv6. It is not intended as a permanent solution.
The document defines a method for assigning an interim unique IPv6 address prefix to any site that currently has at least one globally unique IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network.
The motivation for this method is to allow isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration, before they can obtain natuve IPv6 connectivity. It incidentally provides an interim globally uniqueIPv6 address prefix to any site with at least one globally uniqueIPv4 address, even if combined with an IPv4 Network AddressTranslator (NAT).

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 3058 Use of the IDEA Encryption Algorithm in CMS

Authors: S. Teiwes, P. Hartmann, D. Kuenzi.

Date: February 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3058

This memo specifies how to incorporate International Data EncryptionAlgorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide theOIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption.

RFC 3059 Attribute List Extension for the Service Location Protocol

Authors: E. Guttman.

Date: February 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3059

The Service Location Protocol, Version 2 (SLPv2) provides a mechanism for a service to be discovered in a single exchange of messages.This exchange of messages does not presently include any of the service's attributes. This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information.

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 3061 A URN Namespace of Object Identifiers

Authors: M. Mealling.

Date: February 2001

Formats: txt html json

Obsoletes: RFC 3001

Status: INFORMATIONAL

DOI: 10.17487/RFC 3061

This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). It obsoletes RFC 3001.

RFC 3062 LDAP Password Modify Extended Operation

Authors: K. Zeilenga.

Date: February 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3062

The integration of the Lightweight Directory Access Protocol (LDAP) and external authentication services has introduced non-DN authentication identities and allowed for non-directory storage of passwords. As such, mechanisms which update the directory (e.g.,Modify) cannot be used to change a user's password. This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used.

RFC 3063 MPLS Loop Prevention Mechanism

Authors: Y. Ohba, Y. Katsube, E. Rosen, P. Doolan.

Date: February 2001

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3063

This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. The mechanism is compatible with, but does not require, VC merge. The mechanism can be used with either the ordered downstream-on-demand allocation or ordered downstream allocation. The amount of information that must be passed in a protocol message is tightly bounded (i.e., no path- vector is used). When a node needs to change its next hop, a distributed procedure is executed, but only nodes which are downstream of the change are involved.

RFC 3064 MGCP CAS Packages

Authors: B. Foster.

Date: February 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3064

This document contains a collection of media gateway ChannelAssociated Signaling (CAS) packages for R1 CAS, North American CAS,CAS PBX interconnect as well as basic FXO support. Included are six packages. The "MS" package covers MF single stage dialing trunks.This includes wink start and immediate start PBX DID/DOD trunks as well as basic R1 and Feature Group D (FGD) Terminating protocol [3].The "DT "package covers immediate start and basic DTMF and dial-pulse trunks and the "BL" package covers the interface to a basic PBX(digital or FXS interface). In addition to the Terminating protocol, there are three other FGD protocols described in [3]. These includeEAIN and EANA which is covered by the enclosed "MD" package and theOperator Service Signaling protocol which is handled by the "MO" package. Support for basic FXO interconnect is provided by "DO" package.

RFC 3065 Autonomous System Confederations for BGP

Authors: P. Traina, D. McPherson, J. Scudder.

Date: February 2001

Formats: txt html json

Obsoletes: RFC 1965

Obsoleted by: RFC 5065

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3065

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/InternetProtocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.
This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.

RFC 3066 Tags for the Identification of Languages

Authors: H. Alvestrand.

Date: January 2001

Formats: txt json html

Obsoletes: RFC 1766

Obsoleted by: RFC 4646, RFC 4647

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3066

This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags.

RFC 3067 TERENA'S Incident Object Description and Exchange Format Requirements

Authors: J. Arvidsson, A. Cormack, Y. Demchenko, J. Meijer.

Date: February 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3067

The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (ComputerSecurity Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements.Examples are used to illustrate the requirements where necessary.

RFC 3068 An Anycast Prefix for 6to4 Relay Routers

Authors: C. Huitema.

Date: June 2001

Formats: txt html json

Obsoleted by: RFC 7526

Status: HISTORIC

DOI: 10.17487/RFC 3068

This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned NumbersAuthority) of the "6to4 relay anycast prefix."

RFC 3069 VLAN Aggregation for Efficient IP Address Allocation

Authors: D. McPherson, B. Dykes.

Date: February 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3069

This document introduces the concept of Virtual Local Area Network(VLAN) aggregation as it relates to IPv4 address allocation. A mechanism is described by which hosts that reside in the same physical switched infrastructure, but separate virtual broadcast domains, are addressed from the same IPv4 subnet and share a common default gateway IP address, thereby removing the requirement of a dedicated IP subnet for each virtual Local Area Network (LAN) orMetropolitan Area Network (MAN).
Employing such a mechanism significantly decreases IPv4 address consumption in virtual LANs and MANs. It may also ease administration of IPv4 addresses within the network.

RFC 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay

Authors: V. Rawat, R. Tio, S. Nanji, R. Verma.

Date: February 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3070

Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnelPoint-to-Point (PPP) sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over the User DatagramProtocol (UDP) and the Internet Protocol (IP). This document describes how L2TP is implemented over Frame Relay Permanent VirtualCircuits (PVCs) and Switched Virtual Circuits (SVCs).

RFC 3071 Reflections on the DNS, RFC 1591, and Categories of Domains

Authors: J. Klensin.

Date: February 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3071

RFC 1591, "Domain Name System Structure and Delegation", laid out the basic administrative design and principles for the allocation and administration of domains, from the top level down. It was written before the introduction of the world wide web (WWW) and rapid growth of the Internet put significant market, social, and political pressure on domain name allocations. In recent years, 1591 has been cited by all sides in various debates, and attempts have been made by various bodies to update it or adjust its provisions, sometimes under pressures that have arguably produced policies that are less well thought out than the original. Some of those efforts have begun from misconceptions about the provisions of 1591 or the motivation for those provisions. The current directions of the Internet Corporation for Assigned Names and Numbers (ICANN) and other groups who now determine the Domain Name System (DNS) policy directions appear to be drifting away from the policies and philosophy of 1591. This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how1591 might have been interpreted and adjusted by the InternetAssigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. An earlier variation of this memo was submitted to ICANN as a comment on its evolving Top-level Domain (TLD) policies.

RFC 3072 Structured Data Exchange Format (SDXF)

Authors: M. Wildgrube.

Date: March 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3072

This specification describes an all-purpose interchange format for use as a file format or for net-working. Data is organized in chunks which can be ordered in hierarchical structures. This format is self-describing and CPU-independent.

RFC 3073 Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration

Authors: J. Collins.

Date: March 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3073

This document describes the registration of the Multipurpose InternetMail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification.
A Portable Font Resource (PFR) contains a set of glyph shapes. Each glyph shape is associated with a character code. The PFR format is designed to be both compact and platform-independent. It is intended to facilitate accurate rendering of fonts in all environments whether or not they have the required fonts already installed.

RFC 3074 DHC Load Balancing Algorithm

Authors: B. Volz, S. Gonczi, T. Lemon, R. Stevens.

Date: February 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3074

This document proposes a method of algorithmic load balancing. It enables multiple, cooperating servers to decide which one should service a client, without exchanging any information beyond initial configuration.
The server selection is based on the servers hashing client MediaAccess Control (MAC) addresses when multiple Dynamic HostConfiguration Protocol (DHCP) servers are available to service DHCP clients. The proposed technique provides for efficient server selection when multiple DHCP servers offer services on a network without requiring any changes to existing DHCP clients. The same method is proposed to select the target server of a forwarding agent such as a Bootstrap Protocol (BOOTP) relay.

RFC 3075 XML-Signature Syntax and Processing

Authors: D. Eastlake 3rd, J. Reagle, D. Solo.

Date: March 2001

Formats: txt html json

Obsoleted by: RFC 3275

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3075

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.

RFC 3076 Canonical XML Version 1.0

Authors: J. Boyer.

Date: March 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3076

Any XML (Extensible Markup Language) document is part of a set of XML documents that are logically equivalent within an application context, but which vary in physical representation based on syntactic changes permitted by XML 1.0 and Namespaces in XML. This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. Except for limitations regarding a few unusual cases, if two documents have the same canonical form, then the two documents are logically equivalent within the given application context. Note that two documents may have differing canonical forms yet still be equivalent in a given context based on application-specific equivalence rules for which no generalized XML specification could account.

RFC 3077 A Link-Layer Tunneling Mechanism for Unidirectional Links

Authors: E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang.

Date: March 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3077

This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. The "receiver" uses a link-layer tunneling mechanism to forward datagrams to "feeds" over a separate bidirectional IP (Internet Protocol) network. As it is implemented at the link-layer, protocols in addition to IP may also be supported by this mechanism.

RFC 3078 Microsoft Point-To-Point Encryption (MPPE) Protocol

Authors: G. Pall, G. Zorn.

Date: March 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3078

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Microsoft Point to PointEncryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets.

RFC 3079 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)

Authors: G. Zorn.

Date: March 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3079

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
Microsoft Point to Point Encryption (MPPE) is a means of representingPPP packets in an encrypted form. MPPE uses the RSA RC4 algorithm to provide data confidentiality. The length of the session key to be used for initializing encryption tables can be negotiated. MPPE currently supports 40-bit, 56-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 in the Compression Control Protocol.
This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products.
MPPE itself (including the protocol used to negotiate its use, the details of the encryption method used and the algorithm used to change session keys during a session) is described in RFC 3078.

RFC 3080 The Blocks Extensible Exchange Protocol Core

Authors: M. Rose.

Date: March 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3080

This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP(Blocks Extensible Exchange Protocol) core. BEEP permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.

RFC 3081 Mapping the BEEP Core onto TCP

Authors: M. Rose.

Date: March 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3081

This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection.

RFC 3082 Notification and Subscription for SLP

Authors: J. Kempf, J. Goldschmidt.

Date: March 2001

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3082

The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears.In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling.

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 3084 COPS Usage for Policy Provisioning (COPS-PR)

Authors: K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith.

Date: March 2001

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 3084

This document describes the use of the Common Open Policy Service(COPS) protocol for support of policy provisioning (COPS-PR). This specification is independent of the type of policy being provisioned(QoS, Security, etc.) but focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs.The protocol extensions described in this document do not make any assumptions about the policy data model being communicated, but describe the message formats and objects that carry the modeled policy data.

RFC 3085 URN Namespace for NewsML Resources

Authors: A. Coates, D. Allen, D. Rivers-Moore.

Date: March 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3085

This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. A NewsItem is an information resource that is expressible as a NewsML element within a NewsML document conforming to the NewsML Document Type Declaration (DTD) as defined by the International Press Telecommunications Council (IPTC).

RFC 3086 Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification

Authors: K. Nichols, B. Carpenter.

Date: April 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3086

The differentiated services framework enables quality-of-service provisioning within a network domain by applying rules at the edges to create traffic aggregates and coupling each of these with a specific forwarding path treatment in the domain through use of a codepoint in the IP header. The diffserv WG has defined the general architecture for differentiated services and has focused on the forwarding path behavior required in routers, known as "per-hop forwarding behaviors" (or PHBs). The WG has also discussed functionality required at diffserv (DS) domain edges to select(classifiers) and condition (e.g., policing and shaping) traffic according to the rules. Short-term changes in the QoS goals for a DS domain are implemented by changing only the configuration of these edge behaviors without necessarily reconfiguring the behavior of interior network nodes.
The next step is to formulate examples of how forwarding path components (PHBs, classifiers, and traffic conditioners) can be used to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behavior, orPDB, to describe the behavior experienced by a particular set of packets as they cross a DS domain. A PDB is characterized by specific metrics that quantify the treatment a set of packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain. A PDB specifies a forwarding path treatment for a traffic aggregate and, due to the role that particular choices of edge and
PHB configuration play in its resulting attributes, it is where the forwarding path and the control plane interact. The measurable parameters of a PDB should be suitable for use in Service LevelSpecifications at the network edge.
This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to theDiffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions.

RFC 3087 Control of Service Context using SIP Request-URI

Authors: B. Campbell, R. Sparks.

Date: April 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3087

This memo provides information for the Internet community. It describes a useful way to conceptualize the use of the standard SIP(Session Initiation Protocol) Request-URI (Uniform ResourceIdentifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543.
In a conventional telephony environment, extended service applications often use call state information, such as calling party, called party, reason for forward, etc, to infer application context.In a SIP/2.0 call, much of this information may be either non- existent or unreliable. This document proposes a mechanism to communicate context information to an application. Under this proposal, a client or proxy can communicate context through the use of a distinctive Request-URI. This document continues with examples of how this mechanism could be used in a voice mail application.

RFC 3088 OpenLDAP Root Service An experimental LDAP referral service

Authors: K. Zeilenga.

Date: April 2001

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3088

The OpenLDAP Project is operating an experimental LDAP (LightweightDirectory Access Protocol) referral service known as the "OpenLDAPRoot Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain NameSystem location of services resource records). This document describes this service.

RFC 3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism

Authors: H. Kitamura.

Date: April 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3089

This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes.
It is based on the SOCKS protocol [SOCKSv5]. By applying the SOCKS mechanism to the heterogeneous communications and relaying two"terminated" IPv4 and IPv6 connections at the "application layer"(the SOCKS server), the SOCKS-based IPv6/IPv4 gateway mechanism is accomplished.
Since it is accomplished without introducing new protocols, it provides the same communication environment that is provided by theSOCKS mechanism. The same appearance is provided to the heterogeneous communications. No conveniences or functionalities of current communications are sacrificed.

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 3091 Pi Digit Generation Protocol

Authors: H. Kennedy.

Date: 1 April 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3091

This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers.

RFC 3092 Etymology of "Foo"

Authors: D. Eastlake 3rd, C. Manros, E. Raymond.

Date: 1 April 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3092

Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency.

RFC 3093 Firewall Enhancement Protocol (FEP)

Authors: M. Gaynor, S. Bradner.

Date: 1 April 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3093

Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1].However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose theFirewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. With no cooperation from a firewall operator, the FEP allows ANY application to traverse aFirewall. Our methodology is to layer any application layerTransmission Control Protocol/User Datagram Protocol (TCP/UDP) packets over the HyperText Transfer Protocol (HTTP) protocol, sinceHTTP packets are typically able to transit Firewalls. This scheme does not violate the actual security usefulness of a Firewall, sinceFirewalls are designed to thwart attacks from the outside and to ignore threats from within. The use of FEP is compatible with the current Firewall security model because it requires cooperation from a host inside the Firewall. FEP allows the best of both worlds: the security of a firewall, and transparent tunneling thought the firewall.

RFC 3094 Tekelec's Transport Adapter Layer Interface

Authors: D. Sprague, R. Benedyk, D. Brendes, J. Keller.

Date: April 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3094

This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. Since the Gateway is the central point of signaling information, not only does it provide transportation of signaling from one network to another, but it can also provide additional functions such as protocol translation, security screening, routing information, and seamless access to Intelligent Network (IN) services on both networks.
The Transport Adapter Layer Interface (TALI) is the proposed interface, which provides TCAP (Transaction Capability ApplicationPart), ISUP (ISDN User Part), and MTP (Mail Transport Protocol) messaging over TCP/IP. In addition, TALI provides SCCP (SignallingConnection Control Part) Management (SCMG), MTP Primitives, dynamic registration of circuits, and routing of call control messages based on circuit location.

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 3096 Requirements for robust IP/UDP/RTP header compression

Authors: M. Degermark, Ed..

Date: July 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3096

This document contains requirements for robust IP/UDP/RTP (InternetProtocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression)WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP.

RFC 3097 RSVP Cryptographic Authentication -- Updated Message Type Value

Authors: R. Braden, L. Zhang.

Date: April 2001

Formats: txt json html

Updates: RFC 2747

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3097

This memo resolves a duplication in the assignment of RSVP MessageTypes, by changing the Message Types assigned by RFC 2747 toChallenge and Integrity Response messages.

RFC 3098 How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$

Authors: T. Gavin, D. Eastlake 3rd, S. Hambridge.

Date: April 2001

Formats: txt html json

Also: FYI 0038

Status: INFORMATIONAL

DOI: 10.17487/RFC 3098

This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. Some measure of clarity will also be added to the definitions, dangers, and details inherent to Internet Marketing.

RFC 3099 Request for Comments Summary RFC Numbers 3000-3099

Authors: S. Ginoza.

Date: November 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3099

RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option

Authors: P. Murphy.

Date: January 2003

Formats: txt html json

Obsoletes: RFC 1587

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3101

This memo documents an optional type of Open Shortest Path First(OSPF) area that is somewhat humorously referred to as a "not-so- stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion.
The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and ofRFC 1587 will interoperate.

RFC 3102 Realm Specific IP: Framework

Authors: M. Borella, J. Lo, D. Grabelsky, G. Montenegro.

Date: October 2001

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3102

This document examines the general framework of Realm Specific IP(RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols.

RFC 3103 Realm Specific IP: Protocol Specification

Authors: M. Borella, D. Grabelsky, J. Lo, K. Taniguchi.

Date: October 2001

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3103

This document presents a protocol with which to implement RealmSpecific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port.In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway.

RFC 3104 RSIP Support for End-to-end IPsec

Authors: G. Montenegro, M. Borella.

Date: October 2001

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3104

This document proposes mechanisms that enable Realm Specific IP(RSIP) to handle end-to-end IPsec (IP Security).

RFC 3105 Finding an RSIP Server with SLP

Authors: J. Kempf, G. Montenegro.

Date: October 2001

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3105

This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. ServiceLocation Protocol (SLP) is an IETF standards track protocol specifically designed to allow clients to find servers offering particular services. Since RSIP (Realm Specific IP) clients require a mechanism to discover RSIP servers, SLP is a natural match for a solution. The service type template is the basis for an InternetAssigned Numbers Authority (IANA) standard definition of the advertisements offered by RSIP servers, an important step toward interoperability.

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 3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections

Authors: R. Kumar, M. Mostafa.

Date: May 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3108

This document describes conventions for using the Session DescriptionProtocol (SDP) described in RFC 2327 for controlling ATM BearerConnections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. This list of conventions is meant to be exhaustive. Individual applications can use subsets of these conventions. Further, these conventions are meant to comply strictly with the SDP syntax as defined in RFC 2327.

RFC 3109 Request to Move STD 39 to Historic Status

Authors: R. Braden, R. Bush, J. Klensin.

Date: May 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3109

This memo changes the status of STD 39, BBN Report 1822,"Specification of the Interconnection of a Host and an IMP", fromStandard to Historic.

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 3111 Service Location Protocol Modifications for IPv6

Authors: E. Guttman.

Date: May 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3111

This document defines the Service Location Protocol Version 2's(SLPv2) use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor.
This document does not describe how to use SLPv1 over IPv6 networks.There is at the time of this publication no implementation or deployment of SLPv1 over IPv6. It is RECOMMENDED that SLPv2 be used in general, and specifically on networks which support IPv6.

RFC 3112 LDAP Authentication Password Schema

Authors: K. Zeilenga.

Date: May 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3112

This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This attribute type holds values derived from the user's password(s) (commonly using cryptographic strength one-way hash). authPassword is intended to used instead of userPassword.

RFC 3113 3GPP-IETF Standardization Collaboration

Authors: K. Rosenbrock, R. Sanmugam, S. Bradner, J. Klensin.

Date: June 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3113

This document describes the standardization collaboration between3GPP and IETF.

RFC 3114 Implementing Company Classification Policy with the S/MIME Security Label

Authors: W. Nicolls.

Date: May 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3114

This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples.

RFC 3115 Mobile IP Vendor/Organization-Specific Extensions

Authors: G. Dommety, K. Leung.

Date: April 2001

Formats: txt html json

Obsoletes: RFC 3025

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3115

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes.

RFC 3116 Methodology for ATM Benchmarking

Authors: J. Dunn, C. Martin.

Date: June 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3116

This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM (AsynchronousTransfer Mode) based switching devices. In addition to defining the tests this document also describes specific formats for reporting the results of the tests.
This memo is a product of the Benchmarking Methodology Working Group(BMWG) of the Internet Engineering Task Force (IETF).

RFC 3117 On the Design of Application Protocols

Authors: M. Rose.

Date: November 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3117

This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). BXXP is a generic application protocol framework for connection-oriented, asynchronous interactions. The framework permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.

RFC 3118 Authentication for DHCP Messages

Authors: R. Droms, Ed., W. Arbaugh, Ed..

Date: June 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3118

This document defines a new Dynamic Host Configuration Protocol(DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. DHCP provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts.Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages.

RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio

Authors: R. Finlayson.

Date: June 2001

Formats: txt html json

Obsoleted by: RFC 5219

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3119

This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss.

RFC 3120 A URN Namespace for XML.org

Authors: K. Best, N. Walsh.

Date: June 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3120

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of StructuredInformation Standards (OASIS) for naming persistent resources stored in the XML.org repository (such as XML (Extensible Markup Language)Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents).

RFC 3121 A URN Namespace for OASIS

Authors: K. Best, N. Walsh.

Date: June 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3121

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of StructuredInformation Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible MarkupLanguage) Document Type Definitions, XML Schemas, Namespaces,Stylesheets, and other documents).

RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification

Authors: A. Conta.

Date: June 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3122

This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. These extensions are called InverseNeighbor Discovery. The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior.

RFC 3123 A DNS RR Type for Lists of Address Prefixes (APL RR)

Authors: P. Koch.

Date: June 2001

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3123

The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists.

RFC 3124 The Congestion Manager

Authors: H. Balakrishnan, S. Seshan.

Date: June 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3124

This document describes the Congestion Manager (CM), an end-system module that:
(i) Enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and
(ii) Allows applications to easily adapt to network congestion.

RFC 3125 Electronic Signature Policies

Authors: J. Ross, D. Pinkas, N. Pope.

Date: September 2001

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3125

This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements.
A signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation.
The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied.
To allow for the automatic processing of an electronic signature another part of the signature policy specifies the electronic rules for the creation and validation of the electronic signature in a computer processable form. In the current document the format of the signature policy is defined using ASN.1.
The contents of this document is based on the signature policy defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org.

RFC 3126 Electronic Signature Formats for long term electronic signatures

Authors: D. Pinkas, J. Ross, N. Pope.

Date: September 2001

Formats: txt json html

Obsoleted by: RFC 5126

Status: INFORMATIONAL

DOI: 10.17487/RFC 3126

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny(i.e., repudiates the validity of the signature).
The format can be considered as an extension to RFC 2630 and RFC2634, where, when appropriate additional signed and unsigned attributes have been defined.
The contents of this Informational RFC is technically equivalent toETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org

RFC 3127 Authentication, Authorization, and Accounting: Protocol Evaluation

Authors: D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, M. Stevens, B. Wolff.

Date: June 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3127

This memo represents the process and findings of the Authentication,Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC2989. Due to time constraints of this report, this document is not as fully polished as it might have been desired. But it remains mostly in this state to document the results as presented.

RFC 3128 Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)

Authors: I. Miller.

Date: June 2001

Formats: txt html json

Updates: RFC 1858

Status: INFORMATIONAL

DOI: 10.17487/RFC 3128

This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the "Tiny Fragment Attack" described in section 3.1 of the RFC. This document describes the attack and recommends corrective action.

RFC 3129 Requirements for Kerberized Internet Negotiation of Keys

Authors: M. Thomas.

Date: June 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3129

The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key.

RFC 3130 Notes from the State-Of-The-Technology: DNSSEC

Authors: E. Lewis.

Date: June 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3130

This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting.

RFC 3131 3GPP2-IETF Standardization Collaboration

Authors: S. Bradner, P. Calhoun, H. Cuschieri, S. Dennett, G. Flynn, M. Lipford, M. McPheters.

Date: June 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3131

This document describes the standardization collaboration between3GPP2 and IETF.

RFC 3132 Dormant Mode Host Alerting ("IP Paging") Problem Statement

Authors: J. Kempf.

Date: June 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3132

This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. The results are specifically directed toward the task undertaken by the design team, and are not meant to be the definitive word on paging for all time, nor to be binding onSeamoby or other working groups, should the situation with regard toIP mobility protocols or radio link support undergo a major change.

RFC 3133 Terminology for Frame Relay Benchmarking

Authors: J. Dunn, C. Martin.

Date: June 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3133

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices.

RFC 3134 Terminology for ATM ABR Benchmarking

Authors: J. Dunn, C. Martin.

Date: June 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3134

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context ofAsynchronous Transfer Mode (ATM) based switching devices supportingABR (Available Bit Rate). The terms defined in this memo will be used in addition to terms defined in RFCs 1242, 2285, and 2544 and2761. This memo is a product of the Benchmarking Methodology WorkingGroup (BMWG) of the Internet Engineering Task Force (IETF).

RFC 3135 Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations

Authors: J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby.

Date: June 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3135

This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. Different types of Performance Enhancing Proxies are described as well as the mechanisms used to improve performance. Emphasis is put on proxies operating with TCP. In addition, motivations for their development and use are described along with some of the consequences of using them, especially in the context of the Internet.

RFC 3136 The SPIRITS Architecture

Authors: L. Slutsman, Ed., I. Faynberg, H. Lu, M. Weissman.

Date: June 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3136

This document describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public SwitchedTelephone Network)and necessitating the interactions between the PSTN and the Internet. (Internet Call Waiting, Internet Caller-IDDelivery, and Internet Call Forwarding are examples of SPIRIT services.) Specifically, it defines the components constituting the architecture and the interfaces between the components.

RFC 3137 OSPF Stub Router Advertisement

Authors: A. Retana, L. Nguyen, R. White, A. Zinin, D. McPherson.

Date: June 2001

Formats: txt json html

Obsoleted by: RFC 6987

Status: INFORMATIONAL

DOI: 10.17487/RFC 3137

This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. In some cases, it is desirable not to route transit traffic via a specific OSPF router.However, OSPF does not specify a standard way to accomplish this.

RFC 3138 Extended Assignments in 233/8

Authors: D. Meyer.

Date: June 2001

Formats: txt html json

Obsoleted by: RFC 5771

Status: INFORMATIONAL

DOI: 10.17487/RFC 3138

This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space.

RFC 3139 Requirements for Configuration Management of IP-based Networks

Authors: L. Sanchez, K. McCloghrie, J. Saperia.

Date: June 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3139

This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP- based networks.

RFC 3140 Per Hop Behavior Identification Codes

Authors: D. Black, S. Brim, B. Carpenter, F. Le Faucheur.

Date: June 2001

Formats: txt json html

Obsoletes: RFC 2836

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3140

This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836.

RFC 3141 CDMA2000 Wireless Data Requirements for AAA

Authors: T. Hiller, P. Walsh, X. Chen, M. Munson, G. Dommety, S. Sivalingham, B. Lim, P. McCann, H. Shiino, B. Hirschman, S. Manning, R. Hsu, H. Koo, M. Lipford, P. Calhoun, C. Lo, E. Jaques, E. Campbell, Y. Xu, S. Baba, T. Ayaki, T. Seki, A. Hameed.

Date: June 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3141

This memo specifies cdma2000 wireless data AAA (Authentication,Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services.

RFC 3142 An IPv6-to-IPv4 Transport Relay Translator

Authors: J. Hagino, K. Yamamoto.

Date: June 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3142

The document describes an IPv6-to-IPv4 transport relay translator(TRT). It enables IPv6-only hosts to exchange {TCP,UDP} traffic withIPv4-only hosts. A TRT system, which locates in the middle, translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa.
The memo talks about how to implement a TRT system using existing technologies. It does not define any new protocols.

RFC 3143 Known HTTP Proxy/Caching Problems

Authors: I. Cooper, J. Dilley.

Date: June 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3143

This document catalogs a number of known problems with World Wide Web(WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. The construction of this document is a joint effort of the Web caching community.

RFC 3144 Remote Monitoring MIB Extensions for Interface Parameters Monitoring

Authors: D. Romascanu.

Date: August 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3144

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.The document proposes an extension to the Remote Monitoring MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface.

RFC 3145 L2TP Disconnect Cause Information

Authors: R. Verma, M. Verma, J. Carlson.

Date: July 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3145

This document provides an extension to the Layer 2 Tunneling Protocol("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. L2TP lacks a mechanism for a host to provide PPP-related disconnect cause information to another host. This information, provided by the extension described in this document, can be useful for accounting and debugging purposes.

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 3147 Generic Routing Encapsulation over CLNS Networks

Authors: P. Christian.

Date: July 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3147

This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network usingGRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS.

RFC 3148 A Framework for Defining Empirical Bulk Transfer Capacity Metrics

Authors: M. Mathis, M. Allman.

Date: July 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3148

This document defines a framework for standardizing multiple BTC(Bulk Transport Capacity) metrics that parallel the permitted transport diversity.

RFC 3149 MGCP Business Phone Packages

Authors: A. Srinath, G. Levendel, K. Fritz, R. Kalyanaram.

Date: September 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3149

This document describes a collection of MGCP (Media Gateway ControlProtocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones.

RFC 3150 End-to-end Performance Implications of Slow Links

Authors: S. Dawkins, G. Montenegro, M. Kojo, V. Magret.

Date: July 2001

Formats: txt json html

Also: BCP 0048

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3150

This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links.
"Very low bit-rate" implies "slower than we would like". This recommendation may be useful in any network where hosts can saturate available bandwidth, but the design space for this recommendation explicitly includes connections that traverse 56 Kb/second modem links or 4.8 Kb/second wireless access links - both of which are widely deployed.
This document discusses general-purpose mechanisms. Where application-specific mechanisms can outperform the relevant general- purpose mechanism, we point this out and explain why.
This document has some recommendations in common with RFC 2689,"Providing integrated services over low-bitrate links", especially in areas like header compression. This document focuses more on traditional data applications for which "best-effort delivery" is appropriate.

RFC 3151 A URN Namespace for Public Identifiers

Authors: N. Walsh, J. Cowan, P. Grosso.

Date: August 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3151

This document describes a URN (Uniform Resource Name) namespace that is designed to allow Public Identifiers to be expressed in URI(Uniform Resource Identifiers) syntax.

RFC 3152 Delegation of IP6.ARPA

Authors: R. Bush.

Date: August 2001

Formats: txt html json

Obsoleted by: RFC 3596

Updates: RFC 2874, RFC 2772, RFC 2766, RFC 2553, RFC 1886

Also: BCP 0049

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3152

This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof.

RFC 3153 PPP Multiplexing

Authors: R. Pazhyannur, I. Ali, C. Fox.

Date: August 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3153

This document describes a method to reduce the PPP (Point-to-PointProtocol) framing overhead used to transport small packets over slow links.

RFC 3154 Requirements and Functional Architecture for an IP Host Alerting Protocol

Authors: J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu.

Date: August 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3154

This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of anIP protocol for alerting dormant IP mobile hosts, commonly called paging.

RFC 3155 End-to-end Performance Implications of Links with Errors

Authors: S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya.

Date: August 2001

Formats: txt json html

Also: BCP 0050

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3155

This document discusses the specific TCP mechanisms that are problematic in environments with high uncorrected error rates, and discusses what can be done to mitigate the problems without introducing intermediate devices into the connection.

RFC 3156 MIME Security with OpenPGP

Authors: M. Elkins, D. Del Torto, R. Levien, T. Roessler.

Date: August 2001

Formats: txt html json

Updates: RFC 2015

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3156

This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose InternetMail Extensions (MIME) security content types described in RFC 1847.

RFC 3157 Securely Available Credentials - Requirements

Authors: A. Arsenault, S. Farrell.

Date: August 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3157

This document describes requirements to be placed on SecurelyAvailable Credentials (SACRED) protocols.

RFC 3158 RTP Testing Strategies

Authors: C. Perkins, J. Rosenberg, H. Schulzrinne.

Date: August 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3158

This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations.

RFC 3159 Structure of Policy Provisioning Information (SPPI)

Authors: K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer.

Date: August 2001

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 3159

This document, the Structure of Policy Provisioning Information(SPPI), defines the adapted subset of SNMP's Structure of ManagementInformation (SMI) used to write Policy Information Base (PIB) modules.
RFC 2748 defines the COPS protocol, and RFC 2749 describes how theCOPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in RFC 3084. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the PolicyInformation Base (PIB). Collections of related Provisioning Classes are defined in a PIB module.

RFC 3160 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force

Authors: S. Harris.

Date: August 2001

Formats: txt json html

Obsoletes: RFC 1718

Obsoleted by: RFC 4677

Status: INFORMATIONAL

DOI: 10.17487/RFC 3160

This document describes the inner workings of IETF meetings andWorking Groups, discusses organizations related to the IETF, and introduces the standards process.

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 3163 ISO/IEC 9798-3 Authentication SASL Mechanism

Authors: R. Zuccherato, M. Nystrom.

Date: August 2001

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3163

This document defines a SASL (Simple Authentication and SecurityLayer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB196 entity authentication.

RFC 3164 The BSD Syslog Protocol

Authors: C. Lonvick.

Date: August 2001

Formats: txt json html

Obsoleted by: RFC 5424

Status: INFORMATIONAL

DOI: 10.17487/RFC 3164

This document describes the observed behavior of the syslog protocol.This protocol has been used for the transmission of event notification messages across networks for many years. While this protocol was originally developed on the University of CaliforniaBerkeley Software Distribution (BSD) TCP/IP system implementations, its value to operations and management has led it to be ported to many other operating systems as well as being embedded into many other networked devices.

RFC 3165 Definitions of Managed Objects for the Delegation of Management Scripts

Authors: D. Levi, J. Schoenwaelder.

Date: August 2001

Formats: txt json html

Obsoletes: RFC 2592

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3165

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers.

RFC 3166 Request to Move RFC 1403 to Historic Status

Authors: D. Meyer, J. Scudder.

Date: August 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3166

RFC 1403, "BGP OSPF Interaction", describes technology which is no longer used. This document requests that RFC 1403 be moved toHistoric status.

RFC 3167 Request to Move RFC 1745 to Historic Status

Authors: D. Meyer, J. Scudder.

Date: August 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3167

RFC 1745, "BGP4/IDRP for IP---OSPF Interaction", describes technology which was never deployed in the public internet. This document requests that RFC 1745 be moved to Historic status.

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 3169 Criteria for Evaluating Network Access Server Protocols

Authors: M. Beadles, D. Mitton.

Date: September 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3169

This document defines requirements for protocols used by NetworkAccess Servers (NAS).

RFC 3170 IP Multicast Applications: Challenges and Solutions

Authors: B. Quinn, K. Almeroth.

Date: September 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3170

This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications.
To this end, the document presents a taxonomy of multicast application I/O models and examples of the services they can support.It then describes the service requirements of these multicast applications, and the recent and ongoing efforts to build protocol solutions to support these services.

RFC 3171 IANA Guidelines for IPv4 Multicast Address Assignments

Authors: Z. Albanna, K. Almeroth, D. Meyer, M. Schipper.

Date: August 2001

Formats: txt json html

Obsoleted by: RFC 5771

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3171

This memo provides guidance for the Internet Assigned NumbersAuthority (IANA) in assigning IPv4 multicast addresses.

RFC 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 3173 IP Payload Compression Protocol (IPComp)

Authors: A. Shacham, B. Monsour, R. Pereira, M. Thomas.

Date: September 2001

Formats: txt html json

Obsoletes: RFC 2393

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3173

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment.

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 3176 InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks

Authors: P. Phaal, S. Panchen, N. McKee.

Date: September 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3176

This memo defines InMon Coporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector.

RFC 3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites

Authors: IAB, IESG.

Date: September 2001

Formats: txt html json

Obsoleted by: RFC 6177

Status: INFORMATIONAL

DOI: 10.17487/RFC 3177

This document provides recommendations to the addressing registries(APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of/48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.
The original recommendations were made in an IAB/IESG statement mailed to the registries on September 1, 2000. This document refines the original recommendation and documents it for the historical record.

RFC 3178 IPv6 Multihoming Support at Site Exit Routers

Authors: J. Hagino, H. Snyder.

Date: October 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3178

The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently- practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP (Interior Gateway Protocol) routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC 2260 by Tony Bates.

RFC 3179 Script MIB Extensibility Protocol Version 1.1

Authors: J. Schoenwaelder, J. Quittek.

Date: October 2001

Formats: txt json html

Obsoletes: RFC 2593

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3179

The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independentScript MIB implementations. The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. A management script is a set of instructions that are executed by a language specific runtime system.

RFC 3180 GLOP Addressing in 233/8

Authors: D. Meyer, P. Lothberg.

Date: September 2001

Formats: txt json html

Obsoletes: RFC 2770

Also: BCP 0053

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3180

This document defines the policy for the use of 233/8 for statically assigned multicast addresses.

RFC 3181 Signaled Preemption Priority Policy Element

Authors: S. Herzog.

Date: October 2001

Formats: txt json html

Obsoletes: RFC 2751

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3181

This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the ResourceReSerVation Protocol (RSVP) and Common Open Policy Service (COPS).
Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow.
This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error in RFC 2751.

RFC 3182 Identity Representation for RSVP

Authors: S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, R. Hess.

Date: October 2001

Formats: txt html json

Obsoletes: RFC 2752

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3182

This document describes the representation of identity information inPOLICY_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP). The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos andPublic Key based user authentication mechanisms. In summary, we describe the use of this identity information in an operational setting.
This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error and a field size definition error in ErrorValue in RFC 2752.

RFC 3183 Domain Security Services using S/MIME

Authors: T. Dean, W. Ottaway.

Date: October 2001

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3183

This document describes how the S/MIME (Secure/Multipurpose InternetMail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'.

RFC 3184 IETF Guidelines for Conduct

Authors: S. Harris.

Date: October 2001

Formats: txt json html

Obsoleted by: RFC 7154

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3184

This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The Guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.

RFC 3185 Reuse of CMS Content Encryption Keys

Authors: S. Farrell, S. Turner.

Date: October 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3185

This document describes a way to include a key identifier in a CMS(Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets.

RFC 3186 MAPOS/PPP Tunneling mode

Authors: S. Shimizu, T. Kawano, K. Murakami, E. Beier.

Date: December 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3186

This document specifies tunneling configuration over MAPOS (MultipleAccess Protocol over SONET/SDH) networks. Using this mode, a MAPOS network can provide transparent point-to-point link for PPP overSONET/SDH (Packet over SONET/SDH, POS) without any additional overhead.

RFC 3187 Using International Standard Book Numbers as Uniform Resource Names

Authors: J. Hakala, H. Walravens.

Date: October 2001

Formats: txt html json

Obsoleted by: RFC 8254

Status: HISTORIC

DOI: 10.17487/RFC 3187

This document discusses how International Standard Book Numbers(ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288.

RFC 3188 Using National Bibliography Numbers as Uniform Resource Names

Authors: J. Hakala.

Date: October 2001

Formats: txt json html

Obsoleted by: RFC 8458

Status: INFORMATIONAL

DOI: 10.17487/RFC 3188

This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288.

RFC 3189 RTP Payload Format for DV (IEC 61834) Video

Authors: K. Kobayashi, A. Ogawa, S. Casner, C. Bormann.

Date: January 2002

Formats: txt json html

Obsoleted by: RFC 6469

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3189

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP).

RFC 3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio

Authors: K. Kobayashi, A. Ogawa, S. Casner, C. Bormann.

Date: January 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3190

This document specifies a packetization scheme for encapsulating12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear).

RFC 3191 Minimal GSTN address format in Internet Mail

Authors: C. Allocchio.

Date: October 2001

Formats: txt json html

Obsoletes: RFC 2303

Updates: RFC 2846

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3191

This memo describes a simple method of encoding Global SwitchedTelephone Network (GSTN) addresses (commonly called "telephone numbers") in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services.

RFC 3192 Minimal FAX address format in Internet Mail

Authors: C. Allocchio.

Date: October 2001

Formats: txt html json

Obsoletes: RFC 2304

Updates: RFC 2846

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3192

This memo describes a simple method of encoding Global SwitchedTelephone Network (GSTN) addresses of facsimile devices in the local-part of Internet email addresses.

RFC 3193 Securing L2TP using IPsec

Authors: B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth.

Date: November 2001

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3193

This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed.

RFC 3194 The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio

Authors: A. Durand, C. Huitema.

Date: November 2001

Formats: txt json html

Updates: RFC 1715

Status: INFORMATIONAL

DOI: 10.17487/RFC 3194

This document provides an update on the "H ratio" defined in RFC1715. It defines a new ratio which the authors claim is easier to understand.

RFC 3195 Reliable Delivery for syslog

Authors: D. New, M. Rose.

Date: November 2001

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3195

The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. The first provides a trivial mapping maximizing backward compatibility. The second provides a more complete mapping. Both provide a degree of robustness and security in message delivery that is unavailable to the usual UDP-based syslog protocol, by providing encryption and authentication over a connection-oriented protocol.

RFC 3196 Internet Printing Protocol/1.1: Implementor's Guide

Authors: T. Hastings, C. Manros, P. Zehler, C. Kugler, H. Holst.

Date: November 2001

Formats: txt html json

Obsoletes: RFC 2639

Status: INFORMATIONAL

DOI: 10.17487/RFC 3196

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP).

RFC 3197 Applicability Statement for DNS MIB Extensions

Authors: R. Austein.

Date: November 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3197

This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status.

RFC 3198 Terminology for Policy-Based Management

Authors: A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry, S. Waldbusser.

Date: November 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3198

This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The document takes the approach and format of RFC 2828, which defines an Internet Security Glossary. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs).

RFC 3199 Request for Comments Summary RFC Numbers 3100-3199

Authors: S. Ginoza.

Date: February 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3199

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 3205 On the use of HTTP as a Substrate

Authors: K. Moore.

Date: February 2002

Formats: txt json html

Obsoleted by: RFC 9205

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3205

Recently there has been widespread interest in using HypertextTransfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms.

RFC 3206 The SYS and AUTH POP Response Codes

Authors: R. Gellens.

Date: February 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3206

This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined.

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 3208 PGM Reliable Transport Protocol Specification

Authors: T. Speakman, J. Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby, T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R. Sumanasekera, L. Vicisano.

Date: December 2001

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3208

Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency.

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 3210 Applicability Statement for Extensions to RSVP for LSP-Tunnels

Authors: D. Awduche, A. Hannan, X. Xiao.

Date: December 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3210

This memo discusses the applicability of "Extensions to RSVP(Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track.

RFC 3211 Password-based Encryption for CMS

Authors: P. Gutmann.

Date: December 2001

Formats: txt json html

Obsoleted by: RFC 3369, RFC 3370

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3211

This document provides a method of encrypting data using user- supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption.

RFC 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 3213 Applicability Statement for CR-LDP

Authors: J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright.

Date: January 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3213

This document discusses the applicability of Constraint-Based LSPSetup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track.

RFC 3214 LSP Modification Using CR-LDP

Authors: J. Ash, Y. Lee, P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, L. Li.

Date: January 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3214

This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-basedRouted Label Switched Paths) using CR-LDP (Constraint-based RoutedLabel Distribution Protocol) without service interruption. After aCR-LSP is set up, its bandwidth reservation may need to be changed by the network operator, due to the new requirements for the traffic carried on that CR-LSP. The LSP modification feature can be supported by CR-LDP by use of the _modify_value for the _action indicator flag_ in the LSPID TLV. This feature has application in dynamic network resources management where traffic of different priorities and service classes is involved.

RFC 3215 LDP State Machine

Authors: C. Boscher, P. Cheval, L. Wu, E. Gray.

Date: January 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3215

This document provides state machine tables for ATM (AsynchronousTransfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations.
We begin in section 1 by defining a list of terminologies. Then in section 2, we propose two sets of state machine tables for ATM switchLSRs that use downstream-on-demand mode, one method can be used for non-vc merge capable ATM LSRs, while the other one can be used for the vc-merge capable ATM LSRs. In section 3, we provides a state machine for downstream unsolicited mode ATM LSRs.
We focus on the LDP state machines and the associated control blocks used for establishing and maintaining LSPs. We do not describe state machines for the "LDP controller" that is in charge of LDP session initialization, address mapping messages management, routing interface, etc. that is defined in the LDP specification.
Even though the state machines in this document are specific forATM-LSR, they can be easily adapted for other types of LSRs.

RFC 3216 SMIng Objectives

Authors: C. Elliott, D. Harrington, J. Jason, J. Schoenwaelder, F. Strauss, W. Weiss.

Date: December 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3216

This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations.
The purpose of this document is to serve as a set of objectives that a subsequent language specification should try to address. It captures the results of the working group discussions towards consensus on the SMIng objectives.

RFC 3217 Triple-DES and RC2 Key Wrapping

Authors: R. Housley.

Date: December 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3217

This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. These key wrap algorithms were originally published in section 12.6 of RFC 2630. They are republished since these key wrap algorithms have been found to be useful in contexts beyond those supported by RFC 2630.

RFC 3218 Preventing the Million Message Attack on Cryptographic Message Syntax

Authors: E. Rescorla.

Date: January 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3218

This memo describes a strategy for resisting the Million MessageAttack.

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 3220 IP Mobility Support for IPv4

Authors: C. Perkins, Ed..

Date: January 2002

Formats: txt json html

Obsoletes: RFC 2002

Obsoleted by: RFC 3344

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3220

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 3221 Commentary on Inter-Domain Routing in the Internet

Authors: G. Huston.

Date: December 2001

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3221

This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined.
This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.

RFC 3222 Terminology for Forwarding Information Base (FIB) based Router Performance

Authors: G. Trotter.

Date: December 2001

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3222

This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router.

RFC 3224 Vendor Extensions for Service Location Protocol, Version 2

Authors: E. Guttman.

Date: January 2002

Formats: txt json html

Updates: RFC 2608

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3224

This document specifies how the features of the Service LocationProtocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The ServiceLocation Protocol."

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 3227 Guidelines for Evidence Collection and Archiving

Authors: D. Brezinski, T. Killalea.

Date: February 2002

Formats: txt html json

Also: BCP 0055

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3227

A "security incident" as defined in the "Internet Security Glossary",RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident.
If evidence collection is done correctly, it is much more useful in apprehending the attacker, and stands a much greater chance of being admissible in the event of a prosecution.

RFC 3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)

Authors: B. Fenner.

Date: February 2002

Formats: txt json html

Also: BCP 0057

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3228

This memo requests that the IANA create a registry for fields in theIGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields.

RFC 3229 Delta encoding in HTTP

Authors: J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland, A. van Hoff, D. Hellerstein.

Date: January 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3229

This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1.
Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."

RFC 3230 Instance Digests in HTTP

Authors: J. Mogul, A. Van Hoff.

Date: January 2002

Formats: txt json html

Obsoleted by: RFC 9530

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3230

HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1(Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems.

RFC 3231 Definitions of Managed Objects for Scheduling Management Operations

Authors: D. Levi, J. Schoenwaelder.

Date: January 2002

Formats: txt json html

Obsoletes: RFC 2591

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3231

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times.
This document obsoletes RFC 2591.

RFC 3232 Assigned Numbers: RFC 1700 is Replaced by an On-line Database

Authors: J. Reynolds, Ed..

Date: January 2002

Formats: txt html json

Obsoletes: RFC 1700

Status: INFORMATIONAL

DOI: 10.17487/RFC 3232

This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters.

RFC 3233 Defining the IETF

Authors: P. Hoffman, S. Bradner.

Date: February 2002

Formats: txt html json

Also: BCP 0058

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3233

This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many importantIETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is.

RFC 3234 Middleboxes: Taxonomy and Issues

Authors: B. Carpenter, S. Brim.

Date: February 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3234

This document is intended as part of an IETF discussion about"middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive.

RFC 3235 Network Address Translator (NAT)-Friendly Application Design Guidelines

Authors: D. Senie.

Date: January 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3235

This document discusses those things that application designers might wish to consider when designing new protocols. While many commonInternet applications will operate cleanly in the presence of NetworkAddress Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation).

RFC 3236 The 'application/xhtml+xml' Media Type

Authors: M. Baker, P. Stark.

Date: January 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3236

This document defines the 'application/xhtml+xml' MIME media type forXHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers'text/html'.

RFC 3237 Requirements for Reliable Server Pooling

Authors: M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, J. Loughney, M. Stillman.

Date: January 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3237

This document defines a basic set of requirements for reliable server pooling.
The goal of Reliable Server Pooling (RSerPool) is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool.

RFC 3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services

Authors: S. Floyd, L. Daigle.

Date: January 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3238

This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering ofOpen Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user.

RFC 3239 Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations

Authors: C. Kugler, H. Lewis, T. Hastings.

Date: February 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3239

This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet PrintingProtocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects.The remaining operations operate on a new Device object that more closely models a single output device.

RFC 3240 Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration

Authors: D. Clunie, E. Cordonnier.

Date: February 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3240

This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine).The baseline encoding is defined by the DICOM Standards Committee in"Digital Imaging and Communications in Medicine".

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 3242 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP

Authors: L-E. Jonsson, G. Pelletier.

Date: April 2002

Formats: txt json html

Obsoleted by: RFC 4362

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3242

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User DatagramProtocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed inROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet.

RFC 3243 RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression

Authors: L-E. Jonsson.

Date: April 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3243

This document contains requirements for the 0-byte IP/UDP/RTP(Internet Protocol/User Datagram Protocol/Real-Time TransportProtocol) header compression scheme to be developed by the RobustHeader Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.

RFC 3244 Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols

Authors: M. Swift, J. Trostle, J. Brezak.

Date: February 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3244

This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user.

RFC 3245 The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)

Authors: J. Klensin, Ed., IAB.

Date: March 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3245

RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB.It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T StudyGroup 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.

RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior)

Authors: B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis.

Date: March 2002

Formats: txt json html

Obsoletes: RFC 2598

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3246

This document defines a PHB (per-hop behavior) called ExpeditedForwarding (EF). The PHB is a basic building block in theDifferentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598.

RFC 3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)

Authors: A. Charny, J. Bennet, K. Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K. Ramakrishnan.

Date: March 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3247

This document was written during the process of clarification ofRFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revisedEF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures.

RFC 3248 A Delay Bound alternative revision of RFC 2598

Authors: G. Armitage, B. Carpenter, A. Casati, J. Crowcroft, J. Halpern, B. Kumar, J. Schnizlein.

Date: March 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3248

For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At thePittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF)Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in theDiffServ group. At the San Diego IETF meeting in December 2000 theDiffServ working group decided to pursue an alternative re-expression of the EF PHB.

RFC 3249 Implementers Guide for Facsimile Using Internet Mail

Authors: V. Cancio, M. Moldovan, H. Tamura, D. Wing.

Date: September 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3249

This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents.

RFC 3250 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration

Authors: L. McIntyre, G. Parsons, J. Rafferty.

Date: September 2002

Formats: txt html json

Obsoleted by: RFC 3950

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3250

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for InternetFax and its extensions.

RFC 3251 Electricity over IP

Authors: B. Rajagopalan.

Date: 1 April 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3251

Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question.
This document has also been written as a public service. The "Sub-IP" area has been formed to give equal opportunity to those working on technologies outside of traditional IP networking to write complicated IETF documents. There are possibly many who are wondering how to exploit this opportunity and attain high visibility.Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS control for random technologies) as highly amenable for producing a countless number of unimplementable documents. This document illustrates the key ingredients that go into producing any "foo- over-MPLS" document and may be used as a template for all such work.

RFC 3252 Binary Lexical Octet Ad-hoc Transport

Authors: H. Kennedy.

Date: 1 April 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3252

This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications.

RFC 3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)

Authors: G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead.

Date: March 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3253

This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.

RFC 3254 Definitions for talking about directories

Authors: H. Alvestrand.

Date: April 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3254

When discussing systems for making information accessible through theInternet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use.
For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability.
This document discusses one group of such systems which is known under the term, "directories".

RFC 3255 Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads

Authors: N. Jones, C. Murton.

Date: April 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3255

This document describes an extension to the mapping of Point-to-PointProtocol (PPP) into Synchronous Optical NETwork/Synchronous DigitalHierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads.

RFC 3256 The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option

Authors: D. Jones, R. Woundy.

Date: April 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3256

This document proposes a new sub-option to the DHCP (Dynamic HostConfiguration Protocol) Relay Agent Information Option. This new sub-option is for use with DOCSIS (Data-Over-Cable Service InterfaceSpecifications) cable modems and describes a "device class" to which the cable modem belongs. The cable modem signals its device class information to the Relay Agent using DOCSIS signaling, and the RelayAgent forwards the device class information to the DHCP Server which can then make a policy decision based on it.

RFC 3257 Stream Control Transmission Protocol Applicability Statement

Authors: L. Coene.

Date: April 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3257

This document describes the applicability of the Stream ControlTransmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) &Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP.

RFC 3258 Distributing Authoritative Name Servers via Shared Unicast Addresses

Authors: T. Hardie.

Date: April 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3258

This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas.

RFC 3259 A Message Bus for Local Coordination

Authors: J. Ott, C. Perkins, D. Kutscher.

Date: April 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3259

The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms.

RFC 3260 New Terminology and Clarifications for Diffserv

Authors: D. Grossman.

Date: April 2002

Formats: txt html json

Updates: RFC 2474, RFC 2475, RFC 2597

Status: INFORMATIONAL

DOI: 10.17487/RFC 3260

This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC2597. When RFCs 2474 and 2597 advance on the standards track, andRFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the newRFCs.

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 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP)

Authors: J. Rosenberg, H. Schulzrinne.

Date: June 2002

Formats: txt json html

Obsoletes: RFC 2543

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3262

This document specifies an extension to the Session InitiationProtocol (SIP) providing reliable provisional response messages.This extension uses the option tag 100rel and defines the ProvisionalResponse ACKnowledgement (PRACK) method.

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 3266 Support for IPv6 in Session Description Protocol (SDP)

Authors: S. Olson, G. Camarillo, A. B. Roach.

Date: June 2002

Formats: txt json html

Obsoleted by: RFC 4566

Updates: RFC 2327

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3266

This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP).Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses.

RFC 3267 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs

Authors: J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie.

Date: June 2002

Formats: txt json html

Obsoleted by: RFC 4867

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3267

This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both theRTP payload format and the storage format.

RFC 3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)

Authors: P. Chown.

Date: June 2002

Formats: txt html json

Obsoleted by: RFC 5246

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3268

This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) areRC2, RC4, International Data Encryption Algorithm (IDEA), DataEncryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites.

RFC 3269 Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents

Authors: R. Kermode, L. Vicisano.

Date: April 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3269

This document provides general guidelines to assist the authors ofReliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed.

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 3271 The Internet is for Everyone

Authors: V. Cerf.

Date: April 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3271

This document expresses the Internet Society's ideology that theInternet really is for everyone. However, it will only be such if we make it so.

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 3274 Compressed Data Content Type for Cryptographic Message Syntax (CMS)

Authors: P. Gutmann.

Date: June 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3274

This document defines a format for using compressed data as aCryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS).

RFC 3275 (Extensible Markup Language) XML-Signature Syntax and Processing

Authors: D. Eastlake 3rd, J. Reagle, D. Solo.

Date: March 2002

Formats: txt html json

Obsoletes: RFC 3075

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3275

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.

RFC 3276 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing

Authors: B. Ray, R. Abbi.

Date: May 2002

Formats: txt json html

Obsoleted by: RFC 4319

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3276

This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-PairHigh-Speed Digital Subscriber Line (SHDSL) interfaces.

RFC 3277 Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance

Authors: D. McPherson.

Date: April 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3277

This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification.

RFC 3278 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)

Authors: S. Blake-Wilson, D. Brown, P. Lambert.

Date: April 2002

Formats: txt html json

Obsoleted by: RFC 5753

Status: INFORMATIONAL

DOI: 10.17487/RFC 3278

This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). TheECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard.
The readers attention is called to the Intellectual Property Rights section at the end of this document.

RFC 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 3281 An Internet Attribute Certificate Profile for Authorization

Authors: S. Farrell, R. Housley.

Date: April 2002

Formats: txt html json

Obsoleted by: RFC 5755

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3281

This specification defines a profile for the use of X.509 AttributeCertificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications.

RFC 3282 Content Language Headers

Authors: H. Alvestrand.

Date: May 2002

Formats: txt json html

Obsoletes: RFC 1766

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3282

This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC822-like headers, like MIME body parts or Web documents, and an"Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language.

RFC 3283 Guide to Internet Calendaring

Authors: B. Mahoney, G. Babics, A. Taler.

Date: June 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3283

This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), andRFC 2447 (iMIP). The work in progress addressed is "Calendar AccessProtocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work.

RFC 3284 The VCDIFF Generic Differencing and Compression Data Format

Authors: D. Korn, J. MacDonald, J. Mogul, K. Vo.

Date: June 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3284

This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers.

RFC 3285 Using Microsoft Word to create Internet Drafts and RFCs

Authors: M. Gahrns, T. Hain.

Date: May 2002

Formats: txt html json

Obsoleted by: RFC 5385

Status: INFORMATIONAL

DOI: 10.17487/RFC 3285

This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format.

RFC 3286 An Introduction to the Stream Control Transmission Protocol (SCTP)

Authors: L. Ong, J. Yoakum.

Date: May 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3286

This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol.

RFC 3287 Remote Monitoring MIB Extensions for Differentiated Services

Authors: A. Bierman.

Date: July 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3287

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 monitoringDifferentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2(Remote Network Monitoring Management Version 2) MIB.

RFC 3288 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)

Authors: E. O'Tuathail, M. Rose.

Date: June 2002

Formats: txt html json

Obsoleted by: RFC 4227

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3288

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network.
The SOAP is an XML-based (extensible markup language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries.

RFC 3289 Management Information Base for the Differentiated Services Architecture

Authors: F. Baker, K. Chan, A. Smith.

Date: May 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3289

This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated ServicesArchitecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality.

RFC 3290 An Informal Management Model for Diffserv Routers

Authors: Y. Bernet, S. Blake, D. Grossman, A. Smith.

Date: May 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3290

This document proposes an informal management model of DifferentiatedServices (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements(e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers.It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture.

RFC 3291 Textual Conventions for Internet Network Addresses

Authors: M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder.

Date: May 2002

Formats: txt html json

Obsoletes: RFC 2851

Obsoleted by: RFC 4001

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3291

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations.
This document obsoletes RFC 2851.

RFC 3292 General Switch Management Protocol (GSMP) V3

Authors: A. Doria, F. Hellstrand, K. Sundell, T. Worster.

Date: June 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3292

This document describes the General Switch Management ProtocolVersion 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch.The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources andQoS features.

RFC 3293 General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)

Authors: T. Worster, A. Doria, J. Buerkle.

Date: June 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3293

This memo specifies the encapsulation of GSMP (General SwitchManagement Protocol) packets in ATM (Asynchronous Transfer Mode),Ethernet and TCP (Transmission Control Protocol).

RFC 3294 General Switch Management Protocol (GSMP) Applicability

Authors: A. Doria, K. Sundell.

Date: June 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3294

This memo provides an overview of the GSMP (General Switch ManagementProtocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in anATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration.

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 3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories

Authors: K. Zeilenga.

Date: July 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3296

This document details schema and protocol elements for representing and managing named subordinate references in Lightweight DirectoryAccess Protocol (LDAP) Directories.

RFC 3297 Content Negotiation for Messaging Services based on Email

Authors: G. Klyne, R. Iwazaki, D. Crocker.

Date: July 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3297

This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email.
Services such as facsimile and voice messaging need to cope with new message content formats, yet need to ensure that the content of any given message is renderable by the receiving agent. The mechanism described here aims to meet these needs in a fashion that is fully compatible with the current behaviour and expectations of Internet email.

RFC 3298 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements

Authors: I. Faynberg, J. Gato, H. Lu, L. Slutsman.

Date: August 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3298

This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public SwitchedTelephone Network (PSTN) and necessitate the interactions between thePSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, andInternet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlierIETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol.

RFC 3299 Request for Comments Summary RFC Numbers 3200-3299

Authors: S. Ginoza.

Date: December 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3299

RFC 3300 Internet Official Protocol Standards

Authors: J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz.

Date: November 2002

Formats: txt html json

Obsoletes: RFC 3000

Obsoleted by: RFC 3600

Status: HISTORIC

DOI: 10.17487/RFC 3300

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 24, 2002. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.

RFC 3301 Layer Two Tunnelling Protocol (L2TP): ATM access network extensions

Authors: Y. T'Joens, P. Crivellari, B. Sales.

Date: June 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3301

This document augments the procedures described in RFC 2661 to further support ATM SVC (Switched Virtual Circuits) or PVC (PermanentVirtual Circuits) based access networks. L2TP (Layer 2 TunnelingProtocol) specifies a protocol for tunnelling PPP packets over packet based networks and over IP networks in particular. L2TP supports remote access by ISDN and PSTN networks. The extensions defined within this document allow for asymmetric bi-directional call establishment and service selection in the ATM access network.

RFC 3302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration

Authors: G. Parsons, J. Rafferty.

Date: September 2002

Formats: txt json html

Obsoletes: RFC 2302

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3302

This document describes the registration of the MIME sub-type image/tiff. This document refines an earlier sub-type registration in RFC 1528.
This document obsoletes RFC 2302.

RFC 3303 Middlebox communication architecture and framework

Authors: P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan.

Date: August 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3303

A principal objective of this document is to describe the underlying framework of middlebox communications (MIDCOM) to enable complex applications through the middleboxes, seamlessly using a trusted third party. This document and a companion document on MIDCOM requirements ([REQMTS]) have been created as a precursor to rechartering the MIDCOM working group.
There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications, such as SIP andH.323, and peer-to-peer applications, such as Napster and NetMeeting, cannot be identified by merely examining packet headers. Middleboxes implementing Firewall and Network Address Translator services typically embed application intelligence within the device for their operation. The document specifies an architecture and framework in which trusted third parties can be delegated to assist the middleboxes to perform their operation, without resorting to embedding application intelligence. Doing this will allow a middlebox to continue to provide the services, while keeping the middlebox application agnostic.

RFC 3304 Middlebox Communications (midcom) Protocol Requirements

Authors: R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore.

Date: August 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3304

This document specifies the requirements that the MiddleboxCommunication (midcom) protocol must satisfy in order to meet the needs of applications wishing to influence the middlebox function.These requirements were developed with a specific focus on network address translation and firewall middleboxes.

RFC 3305 Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations

Authors: M. Mealling, Ed., R. Denenberg, Ed..

Date: August 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3305

This document, a product of the W3C Uniform Resource Identifier (URI)Interest Group, addresses and attempts to clarify issues pertaining to URIs. This document addresses how URI space is partitioned and the relationship between URIs, URLs, and URNs, describes how URI schemes and URN namespaces ids are registered, and presents recommendations for continued work on this subject.

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 3307 Allocation Guidelines for IPv6 Multicast Addresses

Authors: B. Haberman.

Date: August 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3307

This document specifies guidelines that must be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the MAC layer address.

RFC 3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension

Authors: P. Calhoun, W. Luo, D. McPherson, K. Peirce.

Date: November 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3308

This document describes mechanisms which enable the Layer TwoTunneling Protocol (L2TP) to negotiate desired Per Hop Behavior (PHB) code for the L2TP control connection, as well as individual sessions within an L2TP tunnel.
L2TP provides a standard method for tunneling PPP packets. The current specification provides no provisions for supportingDifferentiated Services (diffserv) over the L2TP control connection or subsequent data sessions. As a result, no standard mechanism currently exists within L2TP to provide L2TP protocol negotiations for service discrimination.

RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change

Authors: J. Stone, R. Stewart, D. Otis.

Date: September 2002

Formats: txt html json

Obsoleted by: RFC 4960

Updates: RFC 2960

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3309

Stream Control Transmission Protocol (SCTP) currently uses an Adler-32 checksum. For small packets Adler-32 provides weak detection of errors. This document changes that checksum and updates SCTP to use a 32 bit CRC checksum.

RFC 3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)

Authors: A. Niemi, J. Arkko, V. Torvinen.

Date: September 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3310

This memo specifies an Authentication and Key Agreement (AKA) based one-time password generation mechanism for Hypertext TransferProtocol (HTTP) Digest access authentication. The HTTPAuthentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The AKA mechanism performs user authentication and session key distribution in Universal MobileTelecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography.

RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method

Authors: J. Rosenberg.

Date: October 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3311

This specification defines the new UPDATE method for the SessionInitiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs.

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 3313 Private Session Initiation Protocol (SIP) Extensions for Media Authorization

Authors: W. Marshall, Ed..

Date: January 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3313

This document describes the need for Quality of Service (QoS) and media authorization and defines a Session Initiation Protocol (SIP) extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains.

RFC 3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards

Authors: M. Wasserman, Ed..

Date: September 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3314

This document contains recommendations from the Internet EngineeringTask Force (IETF) IPv6 Working Group to the Third GenerationPartnership Project (3GPP) community regarding the use of IPv6 in the3GPP standards. Specifically, this document recommends that the 3GPP specify that multiple prefixes may be assigned to each primary PDP context, require that a given prefix must not be assigned to more than one primary PDP context, and allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers.
The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document.

RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Authors: R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney.

Date: July 2003

Formats: txt html json

Obsoleted by: RFC 8415

Updated by: RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283, RFC 7550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3315

The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or concurrently with the latter to obtain configuration parameters.

RFC 3316 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts

Authors: J. Arkko, G. Kuijpers, H. Soliman, J. Loughney, J. Wiljakka.

Date: April 2003

Formats: txt json html

Obsoleted by: RFC 7066

Status: INFORMATIONAL

DOI: 10.17487/RFC 3316

As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making InternetProtocol version 6 (IPv6) mandatory in their specifications.However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on howIPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or UniversalMobile Telecommunications System (UMTS) networks. This document also lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks.

RFC 3317 Differentiated Services Quality of Service Policy Information Base

Authors: K. Chan, R. Sahita, S. Hahn, K. McCloghrie.

Date: March 2003

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 3317

This document describes a Policy Information Base (PIB) for a device implementing the Differentiated Services Architecture. The provisioning classes defined here provide policy control over resources implementing the Differentiated Services Architecture.These provisioning classes can be used with other none DifferentiatedServices provisioning classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirement to device resource capability and usage.

RFC 3318 Framework Policy Information Base

Authors: R. Sahita, Ed., S. Hahn, K. Chan, K. McCloghrie.

Date: March 2003

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 3318

This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol forProvisioning.
Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well- defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB).
One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security.
As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules.However, some PRovisioning Classes are common to all subject- categories (client-types) and need to be present in each.

RFC 3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers

Authors: H. Schulzrinne, B. Volz.

Date: July 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3319

This document defines a Dynamic Host Configuration Protocol version 6(DHCPv6) option that contains a list of domain names or IPv6 addresses that can be mapped to one or more Session InitiationProtocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server.

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 3322 Signaling Compression (SigComp) Requirements & Assumptions

Authors: H. Hannu.

Date: January 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3322

The purpose of this document is to outline requirements and motivations for the development of a scheme for compression and decompression of messages from signaling protocols. In wireless environments and especially in cellular systems, e.g., GSM (GlobalSystem for Mobile communications) and UMTS (Universal MobileTelecommunications System), there is a need to maximize the transport efficiency for data over the radio interface. With the introduction of SIP/SDP (Session Initiation Protocol/Session Description Protocol) to cellular devices, compression of the signaling messages should be considered in order to improve both service availability and quality, mainly by reducing the user idle time, e.g., at call setup.

RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP)

Authors: J. Peterson.

Date: November 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3323

This document defines new mechanisms for the Session InitiationProtocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service.

RFC 3324 Short Term Requirements for Network Asserted Identity

Authors: M. Watson.

Date: November 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3324

A Network Asserted Identity is an identity initially derived by aSession Initiation Protocol (SIP) network intermediary as a result of an authentication process. This document describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and to User Agents securely connected to such networks.
There is no requirement for identities asserted by a UA in a SIP message to be anything other than the user's desired alias.

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 3330 Special-Use IPv4 Addresses

Authors: IANA.

Date: September 2002

Formats: txt html json

Obsoleted by: RFC 5735

Status: INFORMATIONAL

DOI: 10.17487/RFC 3330

This document describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned NumbersAuthority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers.

RFC 3331 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer

Authors: K. Morneault, R. Dantu, G. Sidebottom, B. Bidulock, J. Heitz.

Date: September 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3331

This document defines a protocol for the backhauling of SignalingSystem 7 Message Transfer Part 2 (SS7 MTP2) User signalling messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signalling Gateway (SG) and MediaGateway Controller (MGC). It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 MessageTransfer Part (MTP) to provide transport. The Signalling Gateway would act as a Signalling Link Terminal.

RFC 3332 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)

Authors: G. Sidebottom, Ed., K. Morneault, Ed., J. Pastor-Balbas, Ed..

Date: September 2002

Formats: txt json html

Obsoleted by: RFC 4666

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3332

This memo defines a protocol for supporting the transport of any SS7MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a MediaGateway Controller (MGC) or IP-resident Database, or between twoIP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 MessageTransfer Part (MTP) to provide transport.

RFC 3334 Policy-Based Accounting

Authors: T. Zseby, S. Zander, C. Carle.

Date: October 2002

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3334

This document describes policy-based accounting which is an approach to provide flexibility to accounting architectures. Accounting policies describe the configuration of an accounting architecture in a standardized way. They are used to instrument the accounting architecture and can be exchanged between Authentication,Authorization and Accounting (AAA) entities in order to share configuration information.
This document describes building blocks and message sequences for policy-based accounting in the generic AAA architecture (RFC 2903).Examples are given for the usage of accounting policies in different scenarios. It is also shown how accounting components can be integrated into the AAA authorization framework (RFC 2904). This document does not propose a language for the description of accounting policies. Rather, it is assumed that a suitable policy language can be chosen from existing or upcoming standards.

RFC 3335 MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet

Authors: T. Harding, R. Drummond, C. Shih.

Date: September 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3335

This document describes how to exchange structured business data securely using SMTP transport for Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, ElectronicData Interchange for Administration, Commerce and Transport), XML or other data used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) or OpenPGP security body parts. Authenticated acknowledgements make use of multipart/signed replies to the original SMTP message.

RFC 3336 PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)

Authors: B. Thompson, T. Koren, B. Buffam.

Date: December 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3336

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of ATM Adaptation Layer 2 (AAL2) for framing PPP encapsulated packets.

RFC 3337 Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2

Authors: B. Thompson, T. Koren, B. Buffam.

Date: December 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3337

The Point-to-Point Protocol (PPP) over Asynchronous Transfer Mode(ATM) Adaptation Layer 2 defines the encapsulation that allows a PPP session to be transported over an ATM virtual circuit using the ATMAdaptation Layer 2 (AAL2) adaptation layer. This document defines a set of class extensions to PPP over AAL2 that implement equivalent functionality to Multi Class Multi Link PPP over a single ATM virtual circuit. Instead of using Multi Link PPP as the basis for fragmentation functionality, this document uses the functionality of the Segmentation and Reassembly Service Specific Convergence Sublayer that is already required as the basic encapsulation format of PPP over AAL2.

RFC 3338 Dual Stack Hosts Using "Bump-in-the-API" (BIA)

Authors: S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand.

Date: October 2002

Formats: txt html json

Obsoleted by: RFC 6535

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3338

This document specifies a mechanism of dual stack hosts using a technique called "Bump-in-the-API"(BIA) which allows for the hosts to communicate with other IPv6 hosts using existing IPv4 applications.The goal of this mechanism is the same as that of the Bump-in-the- stack mechanism, but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved without IP header translation.

RFC 3339 Date and Time on the Internet: Timestamps

Authors: G. Klyne, C. Newman.

Date: July 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3339

This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.

RFC 3340 The Application Exchange Core

Authors: M. Rose, G. Klyne, D. Crocker.

Date: July 2002

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 3340

This memo describes Application Exchange (APEX) Core, an extensible, asynchronous message relaying service for application layer programs.

RFC 3341 The Application Exchange (APEX) Access Service

Authors: M. Rose, G. Klyne, D. Crocker.

Date: July 2002

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 3341

This memo describes the Application Exchange (APEX) access service, addressed as the well-known endpoint "apex=access". The access service is used to control use of both the APEX "relaying mesh" and other APEX services.

RFC 3342 The Application Exchange (APEX) Option Party Pack, Part Deux!

Authors: E. Dixon, H. Franklin, J. Kint, G. Klyne, D. New, S. Pead, M. Rose, M. Schwartz.

Date: July 2002

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 3342

Application Exchange (APEX), at its core, provides a best-effort application-layer datagram service. Options are used to alter the semantics of the core service. This memo defines various options to change the default behavior of APEX's "relaying mesh".

RFC 3343 The Application Exchange (APEX) Presence Service

Authors: M. Rose, G. Klyne, D. Crocker.

Date: April 2003

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 3343

This memo describes the Application Exchange (APEX) presence service, addressed as the well-known endpoint "apex=presence". The presence service is used to manage presence information for APEX endpoints.

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 3345 Border Gateway Protocol (BGP) Persistent Route Oscillation Condition

Authors: D. McPherson, V. Gill, D. Walton, A. Retana.

Date: August 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3345

In particular configurations, the BGP scaling mechanisms defined in"BGP Route Reflection - An Alternative to Full Mesh IBGP" and"Autonomous System Confederations for BGP" will introduce persistentBGP route oscillation. This document discusses the two types of persistent route oscillation that have been identified, describes when these conditions will occur, and provides some network design guidelines to avoid introducing such occurrences.

RFC 3346 Applicability Statement for Traffic Engineering with MPLS

Authors: J. Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. Christian, W.S. Lai.

Date: August 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3346

This document describes the applicability of Multiprotocol LabelSwitching (MPLS) to traffic engineering in IP networks. Special considerations for deployment of MPLS for traffic engineering in operational contexts are discussed and the limitations of the MPLS approach to traffic engineering are highlighted.

RFC 3347 Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations

Authors: M. Krueger, R. Haagens.

Date: July 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3347

This document specifies the requirements iSCSI and its related infrastructure should satisfy and the design considerations guiding the iSCSI protocol development efforts. In the interest of timely adoption of the iSCSI protocol, the IPS group has chosen to focus the first version of the protocol to work with the existing SCSI architecture and commands, and the existing TCP/IP transport layer.Both these protocols are widely-deployed and well-understood. The thought is that using these mature protocols will entail a minimum of new invention, the most rapid possible adoption, and the greatest compatibility with Internet architecture, protocols, and equipment.

RFC 3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension

Authors: M. Gahrns, R. Cheng.

Date: July 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3348

The Internet Message Action Protocol (IMAP4) CHILDREN extension provides a mechanism for a client to efficiently determine if a particular mailbox has children, without issuing a LIST "" * or aLIST "" % for each mailbox.

RFC 3349 A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force

Authors: M. Rose.

Date: July 2002

Formats: txt json html

Also: BCP 0059

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3349

As a part of their deliverables, working groups of the IETF may develop BEEP profiles. During the development process, it is desirable to assign a transient identifier to each profile. If the profile is subsequently published as an RFC, then a permanent identifier is subsequently assigned by the IANA.

RFC 3351 User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals

Authors: N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk.

Date: August 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3351

This document presents a set of Session Initiation Protocol(SIP) user requirements that support communications for deaf, hard of hearing and speech-impaired individuals. These user requirements address the current difficulties of deaf, hard of hearing and speech-impaired individuals in using communications facilities, while acknowledging the multi-functional potential of SIP-based communications.
A number of issues related to these user requirements are further raised in this document.
Also included are some real world scenarios and some technical requirements to show the robustness of these requirements on a concept-level.

RFC 3352 Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status

Authors: K. Zeilenga.

Date: March 2003

Formats: txt html json

Obsoletes: RFC 1798

Status: INFORMATIONAL

DOI: 10.17487/RFC 3352

The Connection-less Lightweight Directory Access Protocol (CLDAP) technical specification, RFC 1798, was published in 1995 as aProposed Standard. This document discusses the reasons why the CLDAP technical specification has not been furthered on the Standard Track.This document recommends that RFC 1798 be moved to Historic status.

RFC 3353 Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment

Authors: D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari.

Date: August 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3353

This document offers a framework for IP multicast deployment in anMPLS environment. Issues arising when MPLS techniques are applied toIP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered.

RFC 3354 Internet Open Trading Protocol Version 2 Requirements

Authors: D. Eastlake 3rd.

Date: August 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3354

This document gives requirements for the Internet Open TradingProtocol (IOTP) Version 2 by describing design principles and scope and dividing features into those which will, may, or will not be included.
Version 2 of the IOTP will extend the interoperable framework forInternet commerce capabilities of Version 1 while replacing the XML messaging and digital signature part of IOTP v1 with standards based mechanisms.

RFC 3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)

Authors: A. Singh, R. Turner, R. Tio, S. Nanji.

Date: August 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3355

The Layer Two Tunneling Protocol (L2TP) provides a standard method for transporting the link layer of the Point-to-Point Protocol (PPP) between a dial-up server and a Network Access Server, using a network connection in lieu of a physical point-to-point connection. This document describes the use of an Asynchronous Transfer Mode (ATM) network for the underlying network connection. ATM User-NetworkInterface (UNI) Signaling Specification Version 4.0 or Version 3.1 with ATM Adaptation Layer 5 (AAL5) are supported as interfaces to theATM network.

RFC 3356 Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines

Authors: G. Fishman, S. Bradner.

Date: August 2002

Formats: txt html json

Obsoletes: RFC 2436

Obsoleted by: RFC 6756

Status: INFORMATIONAL

DOI: 10.17487/RFC 3356

This document provides guidance to aid in the understanding of collaboration on standards development between the InternationalTelecommunication Union -- Telecommunication Standardization Sector(ITU-T) and the Internet Society (ISOC) / Internet Engineering TaskForce (IETF). It is an update of and obsoletes RFC 2436. The updates reflect changes in the IETF and ITU-T since RFC 2436 was written. The bulk of this document is common text with ITU-TSupplement 3 to the ITU-T A-Series Recommendations.
Note: This was approved by ITU-T TSAG on 30 November 2001 as aSupplement to the ITU-T A-Series of Recommendations (will be numbered as A-Series Supplement 3).

RFC 3357 One-way Loss Pattern Sample Metrics

Authors: R. Koodli, R. Ravikanth.

Date: August 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3357

Using the base loss metric defined in RFC 2680, this document defines two derived metrics "loss distance" and "loss period", and the associated statistics that together capture loss patterns experienced by packet streams on the Internet. The Internet exhibits certain specific types of behavior (e.g., bursty packet loss) that can affect the performance seen by the users as well as the operators. The loss pattern or loss distribution is a key parameter that determines the performance observed by the users for certain real-time applications such as packet voice and video. For the same loss rate, two different loss distributions could potentially produce widely different perceptions of performance.

RFC 3358 Optional Checksums in Intermediate System to Intermediate System (ISIS)

Authors: T. Przygienda.

Date: August 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3358

This document describes an optional extension to the IntermediateSystem to Intermediate System (ISIS) protocol, used today by severalInternet Service Proviers (ISPs) for routing within their clouds.ISIS is an interior gateway routing protocol developed originally byOSI and used with IP extensions as Interior Gateway Protocol (IGP).ISIS originally does not provide Complete Sequence Numbers ProtocolData (CSNP) and Partial Sequence Numbers Protocol Data Unit (PSNP) checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional Type, Length and Value (TLV) providing checksums.

RFC 3359 Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System

Authors: T. Przygienda.

Date: August 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3359

This document describes implementation codepoints within IntermediateSystem to Intermediate System (IS-IS) used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions asInterior Gateway Protocol (IGP). This document summarizes all Table,Length and Value (TLV) codepoints that are being used by the protocol and its pending extensions.

RFC 3360 Inappropriate TCP Resets Considered Harmful

Authors: S. Floyd.

Date: August 2002

Formats: txt json html

Also: BCP 0060

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3360

This document is being written because there are a number of firewalls in the Internet that inappropriately reset a TCP connection upon receiving certain TCP SYN packets, in particular, packets with flags set in the Reserved field of the TCP header. In this document we argue that this practice is not conformant with TCP standards, and is an inappropriate overloading of the semantics of the TCP reset.We also consider the longer-term consequences of this and similar actions as obstacles to the evolution of the Internet infrastructure.

RFC 3361 Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers

Authors: H. Schulzrinne.

Date: August 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3361

This document defines a Dynamic Host Configuration Protocol(DHCP-for-IPv4) option that contains a list of domain names or IPv4 addresses that can be mapped to one or more Session InitiationProtocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server.

RFC 3362 Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration

Authors: G. Parsons.

Date: August 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3362

This document describes the registration of the MIME sub-type image/t38. The encoding is defined by ITU Recommendation T.38 and is intended for use as an Session Description Protocol (SDP) media descriptor.

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 3364 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)

Authors: R. Austein.

Date: August 2002

Formats: txt json html

Updates: RFC 2673, RFC 2874

Status: INFORMATIONAL

DOI: 10.17487/RFC 3364

The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on.

RFC 3365 Strong Security Requirements for Internet Engineering Task Force Standard Protocols

Authors: J. Schiller.

Date: August 2002

Formats: txt json html

Also: BCP 0061

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3365

It is the consensus of the IETF that IETF standard protocols MUST make use of appropriate strong security mechanisms. This document describes the history and rationale for this doctrine and establishes this doctrine as a best current practice.

RFC 3366 Advice to link designers on link Automatic Repeat reQuest (ARQ)

Authors: G. Fairhurst, L. Wood.

Date: August 2002

Formats: txt html json

Also: BCP 0062

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3366

This document provides advice to the designers of digital communication equipment and link-layer protocols employing link-layerAutomatic Repeat reQuest (ARQ) techniques. This document presumes that the designers wish to support Internet protocols, but may be unfamiliar with the architecture of the Internet and with the implications of their design choices for the performance and efficiency of Internet traffic carried over their links.
ARQ is described in a general way that includes its use over a wide range of underlying physical media, including cellular wireless, wireless LANs, RF links, and other types of channel. This document also describes issues relevant to supporting IP traffic over physical-layer channels where performance varies, and where link ARQ is likely to be used.

RFC 3367 Common Name Resolution Protocol (CNRP)

Authors: N. Popp, M. Mealling, M. Moseley.

Date: August 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3367

People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and type than URLs.Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable for their resources are being used elsewhere and so are unavailable.For the purposes of this document, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource.
This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Although the protocol's primary function is resolution, it is also intended to address issues of internationalization and localization. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is a simple, minimal interoperable core. Mechanisms for extension are provided, so that additional capabilities can be added.

RFC 3368 The 'go' URI Scheme for the Common Name Resolution Protocol

Authors: M. Mealling.

Date: August 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3368

This document defines a URI scheme, 'go:' to be used with the CommonName Resolution Protocol. Specifically it lays out the syntactic components and how those components are used by URI Resolution to find the available transports for a CNRP service. Care should be taken with several of the URI components because, while they may look like components found in other URI schemes, they often do not act like them. The "go" scheme has more in common with the location independent "news" scheme than any other URI scheme.

RFC 3369 Cryptographic Message Syntax (CMS)

Authors: R. Housley.

Date: August 2002

Formats: txt json html

Obsoletes: RFC 2630, RFC 3211

Obsoleted by: RFC 3852

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3369

This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.

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 3371 Layer Two Tunneling Protocol "L2TP" Management Information Base

Authors: E. Caves, P. Calhoun, R. Wheeler.

Date: August 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3371

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 networks using Layer 2Tunneling Protocol (L2TP).

RFC 3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures

Authors: A. Vemuri, J. Peterson.

Date: September 2002

Formats: txt html json

Also: BCP 0063

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3372

The popularity of gateways that interwork between the PSTN (PublicSwitched Telephone Network) and SIP networks has motivated the publication of a set of common practices that can assure consistent behavior across implementations. This document taxonomizes the uses of PSTN-SIP gateways, provides uses cases, and identifies mechanisms necessary for interworking. The mechanisms detail how SIP provides for both 'encapsulation' (bridging the PSTN signaling across a SIP network) and 'translation' (gatewaying).

RFC 3373 Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies

Authors: D. Katz, R. Saluja.

Date: September 2002

Formats: txt html json

Obsoleted by: RFC 5303

Status: INFORMATIONAL

DOI: 10.17487/RFC 3373

The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.
Additionally, the extension allows the robust operation of more than256 point-to-point links on a single router.
This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors.

RFC 3374 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network

Authors: J. Kempf, Ed..

Date: September 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3374

In IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly.In some cases, the host may establish certain context transfer candidate services on subnets that are left behind when the host moves. Examples of such services are Authentication, Authorization, and Accounting (AAA), header compression, and Quality of Service(QoS). In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signaling flows from scratch. In some cases, this process would considerably slow the process of establishing the mobile host on the new subnet. An alternative is to transfer information on the existing state associated with these services, or context, to the new subnet, a process called "context transfer". This document discusses the desirability of context transfer for facilitating seamless IP mobility.

RFC 3375 Generic Registry-Registrar Protocol Requirements

Authors: S. Hollenbeck.

Date: September 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3375

This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models.

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 3377 Lightweight Directory Access Protocol (v3): Technical Specification

Authors: J. Hodges, R. Morgan.

Date: September 2002

Formats: txt html json

Obsoleted by: RFC 4510

Updates: RFC 2251, RFC 2252, RFC 2253, RFC 2254, RFC 2255, RFC 2256, RFC 2829, RFC 2830

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3377

This document specifies the set of RFCs comprising the LightweightDirectory Access Protocol Version 3 (LDAPv3), and addresses the "IESGNote" attached to RFCs 2251 through 2256.

RFC 3378 EtherIP: Tunneling Ethernet Frames in IP Datagrams

Authors: R. Housley, S. Hollenbeck.

Date: September 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3378

This document describes the EtherIP, an early tunneling protocol, to provide informational and historical context for the assignment of IP protocol 97. EtherIP tunnels Ethernet and IEEE 802.3 media access control frames in IP datagrams so that non-IP traffic can traverse anIP internet. The protocol is very lightweight, and it does not provide protection against infinite loops.

RFC 3379 Delegated Path Validation and Delegated Path Discovery Protocol Requirements

Authors: D. Pinkas, R. Housley.

Date: September 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3379

This document specifies the requirements for Delegated PathValidation (DPV) and Delegated Path Discovery (DPD) for Public KeyCertificates. It also specifies the requirements for DPV and DPD policy management.

RFC 3380 Internet Printing Protocol (IPP): Job and Printer Set Operations

Authors: T. Hastings, R. Herriot, C. Kugler, H. Lewis.

Date: September 2002

Formats: txt json html

Updates: RFC 2910, RFC 2911

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3380

This document is an OPTIONAL extension to the Internet PrintingProtocol (IPP/1.0 and IPP/1.1). This document specifies 3 additionalOPTIONAL operations for use with the Internet Printing Protocol/1.0(IPP) and IPP/1.1. The end user, operator, and administrator Set-Job-Attributes and Set-Printer-Attributes operations are used to modify IPP Job objects and Printer objects, respectively. The Get-Printer-Supported-Values administrative operation returns values that the IPP Printer will accept for setting its "xxx-supported" attributes.

RFC 3381 Internet Printing Protocol (IPP): Job Progress Attributes

Authors: T. Hastings, H. Lewis, R. Bergman.

Date: September 2002

Formats: txt json html

Obsoleted by: RFC 8011

Updates: RFC 2910

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3381

This document defines four new Job Description attributes for monitoring job progress to be registered as OPTIONAL extensions to the Internet Printing Protocol (IPP/1.0 and IPP/1.1). These attributes are drawn from the PWG Job Monitoring MIB. This document also defines a new "sheet-collate" Job Template attribute to control sheet collation and to help with the interpretation of the job progress attributes.

RFC 3382 Internet Printing Protocol (IPP): The 'collection' attribute syntax

Authors: R. deBry, T. Hastings, R. Herriot, K. Ocke, P. Zehler.

Date: September 2002

Formats: txt html json

Obsoleted by: RFC 8010, RFC 8011

Updates: RFC 2910, RFC 2911

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3382

This document specifies an OPTIONAL attribute syntax called'collection' for use with the Internet Printing Protocol (IPP/1.0 andIPP/1.1). A 'collection' is a container holding one or more named values, which are called "member" attributes. A collection allows data to be grouped like a PostScript dictionary or a Java Map. This document also specifies the conformance requirements for a definition document that defines a collection attribute. Finally, this document gives some illustrative example collection attribute definitions that are not intended as actual attribute specifications.

RFC 3383 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)

Authors: K. Zeilenga.

Date: September 2002

Formats: txt html json

Obsoleted by: RFC 4520

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3383

This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). This document also provides guidelines to the Internet Assigned Numbers Authority(IANA) describing conditions under which new values can be assigned.

RFC 3384 Lightweight Directory Access Protocol (version 3) Replication Requirements

Authors: E. Stokes, R. Weiser, R. Moats, R. Huber.

Date: October 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3384

This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol(version 3) (LDAPv3). It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories.

RFC 3385 Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations

Authors: D. Sheinwald, J. Satran, P. Thaler, V. Cavanna.

Date: September 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3385

In this memo, we attempt to give some estimates for the probability of undetected errors to facilitate the selection of an error detection code for the Internet Protocol Small Computer SystemInterface (iSCSI).
We will also attempt to compare Cyclic Redundancy Checks (CRCs) with other checksum forms (e.g., Fletcher, Adler, weighted checksums), as permitted by available data.

RFC 3386 Network Hierarchy and Multilayer Survivability

Authors: W. Lai, Ed., D. McDysan, Ed..

Date: November 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3386

This document presents a proposal of the near-term and practical requirements for network survivability and hierarchy in current service provider environments.

RFC 3387 Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network

Authors: M. Eder, H. Chaskar, S. Nag.

Date: September 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3387

The guiding principles in the design of IP network management were simplicity and no centralized control. The best effort service paradigm was a result of the original management principles and the other way around. New methods to distinguish the service given to one set of packets or flows relative to another are well underway.However, as IP networks evolve the management approach of the past may not apply to the Quality of Service (QoS)-capable network envisioned by some for the future. This document examines some of the areas of impact that QoS is likely to have on management and look at some questions that remain to be addressed.

RFC 3388 Grouping of Media Lines in the Session Description Protocol (SDP)

Authors: G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne.

Date: December 2002

Formats: txt json html

Obsoleted by: RFC 5888

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3388

This document defines two Session Description Protocol (SDP) attributes: "group" and "mid". They allow to group together several"m" lines for two different purposes: for lip synchronization and for receiving media from a single flow (several media streams) that are encoded in different formats during a particular session, on different ports and host interfaces.

RFC 3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)

Authors: R. Zopf.

Date: September 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3389

This document describes a Real-time Transport Protocol (RTP) payload format for transporting comfort noise (CN). The CN payload type is primarily for use with audio codecs that do not support comfort noise as part of the codec itself such as ITU-T Recommendations G.711,G.726, G.727, G.728, and G.722.

RFC 3390 Increasing TCP's Initial Window

Authors: M. Allman, S. Floyd, C. Partridge.

Date: October 2002

Formats: txt json html

Obsoletes: RFC 2414

Updates: RFC 2581

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3390

This document specifies an optional standard for TCP to increase the permitted initial window from one or two segment(s) to roughly 4K bytes, replacing RFC 2414. It discusses the advantages and disadvantages of the higher initial window, and includes discussion of experiments and simulations showing that the higher initial window does not lead to congestion collapse. Finally, this document provides guidance on implementation issues.

RFC 3391 The MIME Application/Vnd.pwg-multiplexed Content-Type

Authors: R. Herriot.

Date: December 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3391

The Application/Vnd.pwg-multiplexed content-type, like theMultipart/Related content-type, provides a mechanism for representing objects that consist of multiple components. AnApplication/Vnd.pwg-multiplexed entity contains a sequence of chunks.Each chunk contains a MIME message or a part of a MIME message. EachMIME message represents a component of the compound object, just as a body part of a Multipart/Related entity represents a component. With a Multipart/Related entity, a body part and its reference in some other body part may be separated by many octets. With anApplication/Vnd.pwg-multiplexed entity, a message and its reference in some other message can be made quite close by chunking the message containing the reference. For example, if a long message contains references to images and the producer does not know of the need for each image until it generates the reference, thenApplication/Vnd.pwg-multiplexed allows the consumer to process the reference to the image and the image before it consumes the entire long message. This ability is important in printing and scanning applications. This document defines the Application/Vnd.pwg- multiplexed content-type. It also provides examples of its use.

RFC 3392 Capabilities Advertisement with BGP-4

Authors: R. Chandra, J. Scudder.

Date: November 2002

Formats: txt html json

Obsoletes: RFC 2842

Obsoleted by: RFC 5492

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3392

This document defines a new Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.
This document obsoletes RFC 2842.

RFC 3393 IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)

Authors: C. Demichelis, P. Chimento.

Date: November 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3393

This document refers to a metric for variation in delay of packets across Internet paths. The metric is based on the difference in theOne-Way-Delay of selected packets. This difference in delay is called "IP Packet Delay Variation (ipdv)".
The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. We discuss both in this document.

RFC 3394 Advanced Encryption Standard (AES) Key Wrap Algorithm

Authors: J. Schaad, R. Housley.

Date: September 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3394

The purpose of this document is to make the Advanced EncryptionStandard (AES) Key Wrap algorithm conveniently available to theInternet community. The United States of America has adopted AES as the new encryption standard. The AES Key Wrap algorithm will probably be adopted by the USA for encryption of AES keys. The authors took most of the text in this document from the draft AES KeyWrap posted by NIST.

RFC 3395 Remote Network Monitoring MIB Protocol Identifier Reference Extensions

Authors: A. Bierman, C. Bucci, R. Dietz, A. Warth.

Date: September 2002

Formats: txt json html

Updates: RFC 2895

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3395

This memo defines extensions to the Protocol Identifier Reference document for the identification of application verb information. It updates the Protocol Identifier Reference document but does not obsolete any portion of that document. In particular, it describes the algorithms required to identify protocol operations (verbs) within the protocol encapsulations managed with MIBs such as theRemote Network Monitoring MIB Version 2, RFC 2021.

RFC 3396 Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)

Authors: T. Lemon, S. Cheshire.

Date: November 2002

Formats: txt html json

Updates: RFC 2131

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3396

This document specifies the processing rules for Dynamic HostConfiguration Protocol (DHCPv4) options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing.

RFC 3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option

Authors: B. Aboba, S. Cheshire.

Date: November 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3397

This document defines a new Dynamic Host Configuration Protocol(DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the domain search list used when resolving hostnames usingDNS.

RFC 3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping

Authors: G. Camarillo, A. B. Roach, J. Peterson, L. Ong.

Date: December 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3398

This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and theIntegrated Services Digital Network (ISDN) User Part (ISUP) ofSignaling System No. 7 (SS7). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).

RFC 3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS

Authors: M. Mealling.

Date: October 2002

Formats: txt json html

Obsoletes: RFC 2915, RFC 2168

Updates: RFC 2276

Status: INFORMATIONAL

DOI: 10.17487/RFC 3401

This document specifies the exact documents that make up the completeDynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string.
This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC2168 and RFC 2915, as well as updates RFC 2276.

RFC 3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm

Authors: M. Mealling.

Date: October 2002

Formats: txt html json

Obsoletes: RFC 2915, RFC 2168

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3402

This document describes the Dynamic Delegation Discovery System(DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic DelegationDiscovery System (DDDS) Part One: The Comprehensive 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 3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database

Authors: M. Mealling.

Date: October 2002

Formats: txt html json

Obsoletes: RFC 2915, RFC 2168

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3403

This document describes a Dynamic Delegation Discovery System (DDDS)Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR).
Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic DelegationDiscovery System (DDDS) Part One: The Comprehensive 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 3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)

Authors: M. Mealling.

Date: October 2002

Formats: txt json html

Obsoletes: RFC 2915, RFC 2168

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3404

This document describes a specification for taking Uniform ResourceIdentifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System.
This document is part of a series that is specified in "DynamicDelegation Discovery System (DDDS) Part One: The Comprehensive 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 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 3406 Uniform Resource Names (URN) Namespace Definition Mechanisms

Authors: L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom.

Date: October 2002

Formats: txt html json

Obsoletes: RFC 2611

Obsoleted by: RFC 8141

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3406

This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications inRFC 3401 and RFC 3405. The whole rests on the concept of individual"namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288.

RFC 3407 Session Description Protocol (SDP) Simple Capability Declaration

Authors: F. Andreasen.

Date: October 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3407

This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng.

RFC 3408 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile

Authors: Z. Liu, K. Le.

Date: December 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3408

This document defines an additional mode of the link-layer assistedRObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHCBidirectional Reliable mode (R-mode) to the ones specified forUnidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242.

RFC 3409 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression

Authors: K. Svanbro.

Date: December 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3409

This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers.The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified byThird Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2),European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP andUDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document.

RFC 3410 Introduction and Applicability Statements for Internet-Standard Management Framework

Authors: J. Case, R. Mundy, D. Partain, B. Stewart.

Date: December 2002

Formats: txt json html

Obsoletes: RFC 2570

Status: INFORMATIONAL

DOI: 10.17487/RFC 3410

The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed theSNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard ManagementFramework (SNMPv1) and the second Internet-Standard ManagementFramework (SNMPv2).
The architecture is designed to be modular to allow the evolution of the Framework over time.
The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157,1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570.

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 3413 Simple Network Management Protocol (SNMP) Applications

Authors: D. Levi, P. Meyer, B. Stewart.

Date: December 2002

Formats: txt html json

Obsoletes: RFC 2573

Also: STD 0062

Status: INTERNET STANDARD

DOI: 10.17487/RFC 3413

This document describes five types of Simple Network ManagementProtocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators,Notification Receivers, and Proxy Forwarders.
This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC2573.

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 3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

Authors: B. Wijnen, R. Presuhn, K. McCloghrie.

Date: December 2002

Formats: txt json html

Obsoletes: RFC 2575

Also: STD 0062

Status: INTERNET STANDARD

DOI: 10.17487/RFC 3415

This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes aManagement Information Base (MIB) for remotely managing the configuration parameters for the View-based Access Control Model.This document obsoletes RFC 2575.

RFC 3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)

Authors: R. Presuhn, Ed..

Date: December 2002

Formats: txt html json

Obsoletes: RFC 1905

Also: STD 0062

Status: INTERNET STANDARD

DOI: 10.17487/RFC 3416

This document defines version 2 of the protocol operations for theSimple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMPPDUs. This document obsoletes RFC 1905.

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 3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)

Authors: R. Presuhn, Ed..

Date: December 2002

Formats: txt json html

Obsoletes: RFC 1907

Also: STD 0062

Status: INTERNET STANDARD

DOI: 10.17487/RFC 3418

This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of theSimple Network Management Protocol (SNMPv2).

RFC 3419 Textual Conventions for Transport Addresses

Authors: M. Daniele, J. Schoenwaelder.

Date: December 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3419

This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6.

RFC 3420 Internet Media Type message/sipfrag

Authors: R. Sparks.

Date: November 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3420

This document registers the message/sipfrag Multipurpose InternetMail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed SessionInitiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request.

RFC 3421 Select and Sort Extensions for the Service Location Protocol (SLP)

Authors: W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome.

Date: November 2002

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3421

This document defines two extensions (Select and Sort) for theService Location Protocol (SLP). These extensions allow a User Agent(UA) to request that the Uniform Resource Locator (URL) entries in aService Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load.

RFC 3422 Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS)

Authors: O. Okamoto, M. Maruyama, T. Sajima.

Date: November 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3422

This memo describes a method for forwarding media access control(MAC) frames over Multiple Access Protocol over Synchronous OpticalNetwork/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network(LAN) environment.

RFC 3423 XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0

Authors: K. Zhang, E. Elkin.

Date: November 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3423

This document defines the Common Reliable Accounting for NetworkElement (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems(BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources.
This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations.

RFC 3424 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation

Authors: L. Daigle, Ed., IAB.

Date: November 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3424

As a result of the nature of Network Address Translation (NAT)Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-AddressFixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.
This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal.

RFC 3425 Obsoleting IQUERY

Authors: D. Lawrence.

Date: November 2002

Formats: txt json html

Updates: RFC 1035

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3425

The IQUERY method of performing inverse DNS lookups, specified in RFC1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete.This document updates RFC 1035.

RFC 3426 General Architectural and Policy Considerations

Authors: S. Floyd.

Date: November 2002

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3426

This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed.

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 3429 Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions

Authors: H. Ohta.

Date: November 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3429

This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the'Operation and Maintenance (OAM) Alert Label' that is used by user- plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets.

RFC 3430 Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping

Authors: J. Schoenwaelder.

Date: December 2002

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3430

This memo defines a transport mapping for using the Simple NetworkManagement Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417.

RFC 3431 Sieve Extension: Relational Tests

Authors: W. Segmuller.

Date: December 2002

Formats: txt json html

Obsoleted by: RFC 5231

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3431

This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators.In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields.

RFC 3432 Network performance measurement with periodic streams

Authors: V. Raisanen, G. Grotefeld, A. Morton.

Date: November 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3432

This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations.

RFC 3433 Entity Sensor Management Information Base

Authors: A. Bierman, D. Romascanu, K.C. Norseth.

Date: December 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3433

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 extending the EntityMIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment(such as chassis temperature, fan RPM, power supply voltage).

RFC 3434 Remote Monitoring MIB Extensions for High Capacity Alarms

Authors: A. Bierman, K. McCloghrie.

Date: December 2002

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3434

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 extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB(RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type.

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 3437 Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation

Authors: W. Palter, W. Townsley.

Date: December 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3437

This document defines extensions to the Layer Two Tunneling Protocol(L2TP) for enhanced support of link-specific Point to Point Protocol(PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options betweenL2TP endpoints in advance of PPP LCP negotiation at the far end of anL2TP tunnel, as well as a mechanism for communicating the negotiatedLCP options back to where the native PPP link resides.

RFC 3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update

Authors: W. Townsley.

Date: December 2002

Formats: txt json html

Also: BCP 0068

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3438

This document describes updates to the Internet Assigned NumbersAuthority (IANA) considerations for the Layer Two Tunneling Protocol(L2TP).

RFC 3439 Some Internet Architectural Guidelines and Philosophy

Authors: R. Bush, D. Meyer.

Date: December 2002

Formats: txt json html

Updates: RFC 1958

Status: INFORMATIONAL

DOI: 10.17487/RFC 3439

This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones.

RFC 3440 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines

Authors: F. Ly, G. Bathrick.

Date: December 2002

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3440

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 additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662).

RFC 3441 Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)

Authors: R. Kumar.

Date: January 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3441

This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, andATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol.

RFC 3442 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4

Authors: T. Lemon, S. Cheshire, B. Volz.

Date: December 2002

Formats: txt json html

Updates: RFC 2132

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3442

This document defines a new Dynamic Host Configuration Protocol(DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask.

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 3444 On the Difference between Information Models and Data Models

Authors: A. Pras, J. Schoenwaelder.

Date: January 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3444

There has been ongoing confusion about the differences betweenInformation Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as theInternational Telecommunication Union (ITU) or the DistributedManagement Task Force (DMTF)) fit into the universe of InformationModels and Data Models.
This memo documents the main results of the 8th workshop of theNetwork Management Research Group (NMRG) of the Internet ResearchTask Force (IRTF) hosted by the University of Texas at Austin.

RFC 3445 Limiting the Scope of the KEY Resource Record (RR)

Authors: D. Massey, S. Rose.

Date: December 2002

Formats: txt html json

Obsoleted by: RFC 4033, RFC 4034, RFC 4035

Updates: RFC 2535

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3445

This document limits the Domain Name System (DNS) KEY Resource Record(RR) to only keys used by the Domain Name System Security Extensions(DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub- types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535.

RFC 3446 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)

Authors: D. Kim, D. Meyer, H. Kilmer, D. Farinacci.

Date: January 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3446

This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree ProtocolIndependent Multicast-Sparse Mode (PIM-SM) domain.

RFC 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1

Authors: J. Jonsson, B. Kaliski.

Date: February 2003

Formats: txt json html

Obsoletes: RFC 2437

Obsoleted by: RFC 8017

Status: INFORMATIONAL

DOI: 10.17487/RFC 3447

This memo represents a republication of PKCS #1 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process.

RFC 3448 TCP Friendly Rate Control (TFRC): Protocol Specification

Authors: M. Handley, S. Floyd, J. Padhye, J. Widmer.

Date: January 2003

Formats: txt html json

Obsoleted by: RFC 5348

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3448

This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.

RFC 3449 TCP Performance Implications of Network Path Asymmetry

Authors: H. Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara.

Date: December 2002

Formats: txt html json

Also: BCP 0069

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3449

This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender.
The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link-layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self-clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use.A summary of the recommendations is provided at the end of the document.

RFC 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation

Authors: M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft.

Date: December 2002

Formats: txt html json

Obsoleted by: RFC 5775

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3450

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.Asynchronous Layered Coding combines the Layered Coding Transport(LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender.

RFC 3451 Layered Coding Transport (LCT) Building Block

Authors: M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft.

Date: December 2002

Formats: txt html json

Obsoleted by: RFC 5651

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3451

Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.

RFC 3452 Forward Error Correction (FEC) Building Block

Authors: M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft.

Date: December 2002

Formats: txt json html

Obsoleted by: RFC 5052, RFC 5445

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3452

This document generally describes how to use Forward Error Correction(FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport usingIP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry.The procedures for specifying FEC codes and registering them with theInternet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward ErrorCorrection (FEC) in Reliable Multicast".

RFC 3453 The Use of Forward Error Correction (FEC) in Reliable Multicast

Authors: M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft.

Date: December 2002

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3453

This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC.

RFC 3454 Preparation of Internationalized Strings ("stringprep")

Authors: P. Hoffman, M. Blanchet.

Date: December 2002

Formats: txt html json

Obsoleted by: RFC 7564

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3454

This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings.
This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options.

RFC 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)

Authors: M. Garcia-Martin, E. Henrikson, D. Mills.

Date: January 2003

Formats: txt html json

Obsoleted by: RFC 7315

Status: INFORMATIONAL

DOI: 10.17487/RFC 3455

This document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the 3rd-Generation PartnershipProject (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses.

RFC 3456 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode

Authors: B. Patel, B. Aboba, S. Kelly, V. Gupta.

Date: January 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3456

This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host ConfigurationProtocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. InIPv4, DHCP provides for such remote host configuration.

RFC 3457 Requirements for IPsec Remote Access Scenarios

Authors: S. Kelly, S. Ramamoorthi.

Date: January 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3457

IPsec offers much promise as a secure remote access mechanism.However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios.

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 3460 Policy Core Information Model (PCIM) Extensions

Authors: B. Moore, Ed..

Date: January 2003

Formats: txt html json

Updates: RFC 3060

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3460

This document specifies a number of changes to the Policy CoreInformation Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060.

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 3465 TCP Congestion Control with Appropriate Byte Counting (ABC)

Authors: M. Allman.

Date: February 2003

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3465

This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly.

RFC 3466 A Model for Content Internetworking (CDI)

Authors: M. Day, B. Cain, G. Tomlinson, P. Rzewski.

Date: February 2003

Formats: txt json html

Obsoleted by: RFC 7336

Status: INFORMATIONAL

DOI: 10.17487/RFC 3466

Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called"content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary.

RFC 3467 Role of the Domain Name System (DNS)

Authors: J. Klensin.

Date: February 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3467

This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them.

RFC 3468 The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols

Authors: L. Andersson, G. Swallow.

Date: February 2003

Formats: txt html json

Updates: RFC 3212, RFC 3472, RFC 3475, RFC 3476

Status: INFORMATIONAL

DOI: 10.17487/RFC 3468

This document documents the consensus reached by the MultiprotocolLabel Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions toRSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG.

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 3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)

Authors: Z. Lin, D. Pendarakis.

Date: March 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3474

The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on SynchronousOptical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well asOptical Transport Networks (OTNs).
This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using ResourceReservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network.
This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-TStudy Group 15 in support of ITU's ASON standardization effort.

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 3478 Graceful Restart Mechanism for Label Distribution Protocol

Authors: M. Leelanivas, Y. Rekhter, R. Aggarwal.

Date: February 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3478

This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's(LSR's) control plane restart, specifically by the restart of itsLabel Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart.
The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document).Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here.
The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actualMPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart.
The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study.

RFC 3479 Fault Tolerance for the Label Distribution Protocol (LDP)

Authors: A. Farrel, Ed..

Date: February 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3479

Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum.Many MPLS Label Switching Routers (LSRs) may, therefore, exploitFault Tolerant (FT) hardware or software to provide high availability of the core networks.
The details of how FT is achieved for the various components of an FTLSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDPSpecification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations.
The issues and extensions described here are equally applicable toRFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP).

RFC 3480 Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)

Authors: K. Kompella, Y. Rekhter, A. Kullberg.

Date: February 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3480

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 Constraint-RoutingLabel Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links.

RFC 3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks

Authors: H. Inamura, Ed., G. Montenegro, Ed., R. Ludwig, A. Gurtov, F. Khafizov.

Date: February 2003

Formats: txt html json

Also: BCP 0071

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3481

This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet.

RFC 3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview

Authors: M. Foster, T. McGarry, J. Yu.

Date: February 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3482

This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN).NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters forNP implementation, most of which are not network technology specific.Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF.

RFC 3483 Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR)

Authors: D. Rawlins, A. Kulkarni, M. Bokaemper, K. Chan.

Date: March 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3483

Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point(PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPSReport Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state.

RFC 3484 Default Address Selection for Internet Protocol version 6 (IPv6)

Authors: R. Draves.

Date: February 2003

Formats: txt html json

Obsoleted by: RFC 6724

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3484

This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa.
All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification.

RFC 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 3487 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)

Authors: H. Schulzrinne.

Date: February 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3487

This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session InitiationProtocol (SIP).

RFC 3488 Cisco Systems Router-port Group Management Protocol (RGMP)

Authors: I. Wu, T. Eckert.

Date: February 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3488

This document describes the Router-port Group Management Protocol(RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed.
RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected.

RFC 3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

Authors: J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy.

Date: March 2003

Formats: txt html json

Obsoleted by: RFC 5389

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3489

Simple Traversal of User Datagram Protocol (UDP) Through NetworkAddress Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol(IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them.As a result, it allows a wide variety of applications to work through existing NAT infrastructure.

RFC 3490 Internationalizing Domain Names in Applications (IDNA)

Authors: P. Faltstrom, P. Hoffman, A. Costello.

Date: March 2003

Formats: txt html json

Obsoleted by: RFC 5890, RFC 5891

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3490

Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism calledInternationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so- called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text.

RFC 3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)

Authors: P. Hoffman, M. Blanchet.

Date: March 2003

Formats: txt html json

Obsoleted by: RFC 5891

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3491

This document describes how to prepare internationalized domain name(IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS).

RFC 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 3493 Basic Socket Interface Extensions for IPv6

Authors: R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens.

Date: February 2003

Formats: txt json html

Obsoletes: RFC 2553

Status: INFORMATIONAL

DOI: 10.17487/RFC 3493

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.

RFC 3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status

Authors: K. Zeilenga.

Date: March 2003

Formats: txt html json

Obsoletes: RFC 1484, RFC 1485, RFC 1487, RFC 1777, RFC 1778, RFC 1779, RFC 1781, RFC 2559

Status: INFORMATIONAL

DOI: 10.17487/RFC 3494

This document recommends the retirement of version 2 of theLightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status.

RFC 3495 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration

Authors: B. Beser, P. Duffy, Ed..

Date: March 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3495

This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed withinCableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed.

RFC 3496 Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering

Authors: A. G. Malis, T. Hsiao.

Date: March 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3496

This document specifies a Resource ReSerVation Protocol-TrafficEngineering (RSVP-TE) signaling extension for support of AsynchronousTransfer Mode (ATM) Service Class-aware Multiprotocol Label Switching(MPLS) Traffic Engineering.

RFC 3497 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video

Authors: L. Gharai, C. Perkins, G. Goncher, A. Mankin.

Date: March 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3497

This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by theSociety of Motion Picture and Television Engineers (SMPTE) standard,SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport.

RFC 3498 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures

Authors: J. Kuhfeld, J. Johnson, M. Thatcher.

Date: March 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3498

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 networks usingSynchronous Optical Network (SONET) linear Automatic ProtectionSwitching (APS) architectures.

RFC 3499 Request for Comments Summary RFC Numbers 3400-3499

Authors: S. Ginoza.

Date: December 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3499

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 3503 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)

Authors: A. Melnikov.

Date: March 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3503

The Message Disposition Notification (MDN) facility defined in RFC2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment.
This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products.

RFC 3504 Internet Open Trading Protocol (IOTP) Version 1, Errata

Authors: D. Eastlake.

Date: March 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3504

Since the publication of the RFCs specifying Version 1.0 of theInternet Open Trading Protocol (IOTP), some errors have been noted.This informational document lists these errors and provides corrections for them.

RFC 3505 Electronic Commerce Modeling Language (ECML): Version 2 Requirements

Authors: D. Eastlake.

Date: March 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3505

This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to ExtensibleMarkup Language (XML) syntax, data model, format, and payment processing.

RFC 3506 Requirements and Design for Voucher Trading System (VTS)

Authors: K. Fujimura, D. Eastlake.

Date: March 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3506

Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a "voucher", which is a digital representation of the right to claim goods or services. This document presents a Voucher TradingSystem (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the GenericVoucher Language (GVL), with which diverse types of vouchers can be described.

RFC 3507 Internet Content Adaptation Protocol (ICAP)

Authors: J. Elson, A. Cerpa.

Date: April 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3507

ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services.ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to passHTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses.

RFC 3508 H.323 Uniform Resource Locator (URL) Scheme Registration

Authors: O. Levin.

Date: April 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3508

ITU-T Recommendation H.323 version 4 introduced an H.323-specificUniform Resource Locator (URL). This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority(IANA).

RFC 3509 Alternative Implementations of OSPF Area Border Routers

Authors: A. Zinin, A. Lindem, D. Yeung.

Date: April 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3509

Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers.

RFC 3510 Internet Printing Protocol/1.1: IPP URL Scheme

Authors: R. Herriot, I. McDonald.

Date: April 2003

Formats: txt html json

Updates: RFC 2910

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3510

This memo defines the "ipp" URL (Uniform Resource Locator) scheme.This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910.An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service.

RFC 3511 Benchmarking Methodology for Firewall Performance

Authors: B. Hickman, D. Newman, S. Tadjudin, T. Martin.

Date: April 2003

Formats: txt html json

Obsoleted by: RFC 9411

Status: INFORMATIONAL

DOI: 10.17487/RFC 3511

This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests.
This document is a product of the Benchmarking Methodology WorkingGroup (BMWG) of the Internet Engineering Task Force (IETF).

RFC 3512 Configuring Networks and Devices with Simple Network Management Protocol (SNMP)

Authors: M. MacFaden, D. Partain, J. Saperia, W. Tackabury.

Date: April 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3512

This document is written for readers interested in the InternetStandard Management Framework and its protocol, the Simple NetworkManagement Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks.

RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture

Authors: R. Hinden, S. Deering.

Date: April 2003

Formats: txt json html

Obsoletes: RFC 2373

Obsoleted by: RFC 4291

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3513

This specification defines the addressing architecture of the IPVersion 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses.

RFC 3514 The Security Flag in the IPv4 Header

Authors: S. Bellovin.

Date: 1 April 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3514

Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases.

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 3517 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP

Authors: E. Blanton, M. Allman, K. Fall, L. Wang.

Date: April 2003

Formats: txt json html

Obsoleted by: RFC 6675

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3517

This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data.

RFC 3518 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)

Authors: M. Higashiyama, F. Baker, T. Liao.

Date: April 2003

Formats: txt html json

Obsoletes: RFC 2878

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3518

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
This document defines the NCP for establishing and configuring RemoteBridging for PPP links.
This document obsoletes RFC 2878, which was based on the IEEE802.1D-1993 MAC Bridge. This document extends that specification by improving support for bridge control packets.

RFC 3519 Mobile IP Traversal of Network Address Translation (NAT) Devices

Authors: H. Levkowetz, S. Vaarala.

Date: April 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3519

Mobile IP's datagram tunnelling is incompatible with Network AddressTranslation (NAT). This document presents extensions to the MobileIP protocol and a tunnelling method which permits mobile nodes usingMobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic.

RFC 3520 Session Authorization Policy Element

Authors: L-N. Hamer, B. Gage, B. Kosinski, H. Shieh.

Date: April 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3520

This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP)PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios.

RFC 3521 Framework for Session Set-up with Media Authorization

Authors: L-N. Hamer, B. Gage, H. Shieh.

Date: April 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3521

Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host.
To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in-line with the media streams requested (and authorized) for the session.

RFC 3522 The Eifel Detection Algorithm for TCP

Authors: R. Ludwig, M. Meyer.

Date: April 2003

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3522

The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state.

RFC 3523 Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology

Authors: J. Polk.

Date: April 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3523

This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREPWorking Group during discussions and when writing requirements, gap analysis and other solutions documents.

RFC 3524 Mapping of Media Streams to Resource Reservation Flows

Authors: G. Camarillo, A. Monrad.

Date: April 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3524

This document defines an extension to the Session DescriptionProtocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow.The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF).

RFC 3525 Gateway Control Protocol Version 1

Authors: C. Groves, Ed., M. Pantaleo, Ed., T. Anderson, Ed., T. Taylor, Ed..

Date: June 2003

Formats: txt html json

Obsoletes: RFC 3015

Obsoleted by: RFC 5125

Status: HISTORIC

DOI: 10.17487/RFC 3525

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and aMedia Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.
This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T StudyGroup 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the MegacoE-mail list and incorporated into the Study Group 16 Implementor'sGuide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1.Because of ITU-T renumbering, it was published by the ITU-T asRecommendation H.248.1 (03/2002), Gateway Control Protocol Version 1.
Users of this specification are advised to consult the H.248 Sub- series Implementors' Guide at http://www.itu.int/itudoc/itu- t/com16/implgd for additional corrections and clarifications.

RFC 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)

Authors: T. Kivinen, M. Kojo.

Date: May 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3526

This document defines new Modular Exponential (MODP) Groups for theInternet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096,6144, and 8192 bit Diffie-Hellman groups numbered starting at 14.The selection of the primes for theses groups follows the criteria established by Richard Schroeppel.

RFC 3527 Link Selection sub-option for the Relay Agent Information Option for DHCPv4

Authors: K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy.

Date: April 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3527

This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol(DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host ConfigurationProtocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with theDHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent.

RFC 3528 Mesh-enhanced Service Location Protocol (mSLP)

Authors: W. Zhao, H. Schulzrinne, E. Guttman.

Date: April 2003

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3528

This document describes the Mesh-enhanced Service Location Protocol(mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture.Peer DAs exchange new service registrations in shared scopes via anti-entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally.

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 3530 Network File System (NFS) version 4 Protocol

Authors: S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck.

Date: April 2003

Formats: txt html json

Obsoletes: RFC 3010

Obsoleted by: RFC 7530

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3530

The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in anInternet environment.
This document replaces RFC 3010 as the definition of the NFS version4 protocol.

RFC 3531 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block

Authors: M. Blanchet.

Date: April 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3531

This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments.

RFC 3532 Requirements for the Dynamic Partitioning of Switching Elements

Authors: T. Anderson, J. Buerkle.

Date: May 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3532

This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element(e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party.

RFC 3533 The Ogg Encapsulation Format Version 0

Authors: S. Pfeiffer.

Date: May 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3533

This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams.It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream.

RFC 3534 The application/ogg Media Type

Authors: L. Walleij.

Date: May 2003

Formats: txt html json

Obsoleted by: RFC 5334

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3534

The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the OggBitstream Format developers that it be usable without intellectual property concerns.

RFC 3535 Overview of the 2002 IAB Network Management Workshop

Authors: J. Schoenwaelder.

Date: May 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3535

This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide theIETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

RFC 3536 Terminology Used in Internationalization in the IETF

Authors: P. Hoffman.

Date: May 2003

Formats: txt json html

Obsoleted by: RFC 6365

Status: INFORMATIONAL

DOI: 10.17487/RFC 3536

This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.

RFC 3537 Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key

Authors: J. Schaad, R. Housley.

Date: May 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3537

This document defines two methods for wrapping an HMAC (HashedMessage Authentication Code) key. The first method defined uses aTriple DES (Data Encryption Standard) key to encrypt the HMAC key.The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic MessageSyntax).

RFC 3538 Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)

Authors: Y. Kawatsura.

Date: June 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3538

This document describes detailed Input/Output parameters for theInternet Open Trading Protocol (IOTP) Payment Application ProgrammingInterface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP.

RFC 3539 Authentication, Authorization and Accounting (AAA) Transport Profile

Authors: B. Aboba, J. Wood.

Date: June 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3539

This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols.This includes usage of standards-track RFCs as well as experimental proposals.

RFC 3540 Robust Explicit Congestion Notification (ECN) Signaling with Nonces

Authors: N. Spring, D. Wetherall, D. Ely.

Date: June 2003

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 3540

This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth.The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts.

RFC 3541 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D)

Authors: A. Walsh.

Date: May 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3541

This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality ModelingLanguage (VRML) and Extensible 3D (X3D) files and resources,Extensible Markup Language (XML) Document Type Definitions (DTDs),XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D.

RFC 3542 Advanced Sockets Application Program Interface (API) for IPv6

Authors: W. Stevens, M. Thomas, E. Nordmark, T. Jinmei.

Date: May 2003

Formats: txt html json

Obsoletes: RFC 2292

Status: INFORMATIONAL

DOI: 10.17487/RFC 3542

This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping,Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification(specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum TransmissionUnit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are notIPv6-capable.

RFC 3543 Registration Revocation in Mobile IPv4

Authors: S. Glass, M. Chandra.

Date: August 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3543

This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well.Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the MobileIPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding.

RFC 3544 IP Header Compression over PPP

Authors: T. Koren, S. Casner, C. Bormann.

Date: July 2003

Formats: txt json html

Obsoletes: RFC 2509

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3544

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-PointProtocol (RFC 1661). It defines extensions to the PPP ControlProtocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP,UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545.

RFC 3545 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering

Authors: T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy.

Date: July 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3545

This document describes a header compression scheme for point to point links with packet loss and long delays. It is based onCompressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays.

RFC 3546 Transport Layer Security (TLS) Extensions

Authors: S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright.

Date: June 2003

Formats: txt html json

Obsoleted by: RFC 4366

Updates: RFC 2246

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3546

This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa.

RFC 3547 The Group Domain of Interpretation

Authors: M. Baugher, B. Weis, T. Hardjono, H. Harney.

Date: July 2003

Formats: txt html json

Obsoleted by: RFC 6407

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3547

This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. TheGDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members.

RFC 3548 The Base16, Base32, and Base64 Data Encodings

Authors: S. Josefsson, Ed..

Date: July 2003

Formats: txt json html

Obsoleted by: RFC 4648

Status: INFORMATIONAL

DOI: 10.17487/RFC 3548

This document describes the commonly used base 64, base 32, and base16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets.

RFC 3549 Linux Netlink as an IP Services Protocol

Authors: J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov.

Date: July 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3549

This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component(FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter-process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.).
This document is intended as informational in the context of prior art for the ForCES IETF working group.

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 3553 An IETF URN Sub-namespace for Registered Protocol Parameters

Authors: M. Mealling, L. Masinter, T. Hardie, G. Klyne.

Date: June 2003

Formats: txt html json

Also: BCP 0073

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3553

This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer toIETF-defined resources.

RFC 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec

Authors: S. Bellovin, J. Ioannidis, A. Keromytis, R. Stewart.

Date: July 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3554

This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic.

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 3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth

Authors: S. Casner.

Date: July 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3556

This document defines an extension to the Session DescriptionProtocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-timeTransport Protocol (RTP) session.

RFC 3557 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding

Authors: Q. Xie, Ed..

Date: July 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3557

This document specifies an RTP payload format for encapsulatingEuropean Telecommunications Standards Institute (ETSI) EuropeanStandard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems.

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 3559 Multicast Address Allocation MIB

Authors: D. Thaler.

Date: June 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3559

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 multicast address allocation.

RFC 3560 Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)

Authors: R. Housley.

Date: July 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3560

This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). TheCMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients.

RFC 3561 Ad hoc On-Demand Distance Vector (AODV) Routing

Authors: C. Perkins, E. Belding-Royer, S. Das.

Date: July 2003

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3561

The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times(even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols.

RFC 3562 Key Management Considerations for the TCP MD5 Signature Option

Authors: M. Leech.

Date: July 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3562

The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature.This document addresses the security requirements of that keying material.

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 3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)

Authors: J. Schaad.

Date: July 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3565

This document specifies the conventions for using the AdvancedEncryption Standard (AES) algorithm for encryption with theCryptographic Message Syntax (CMS).

RFC 3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec

Authors: S. Frankel, H. Herbert.

Date: September 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3566

A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96.

RFC 3567 Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication

Authors: T. Li, R. Atkinson.

Date: July 2003

Formats: txt html json

Obsoleted by: RFC 5304

Status: INFORMATIONAL

DOI: 10.17487/RFC 3567

This document describes the authentication of Intermediate System toIntermediate System (IS-IS) Protocol Data Units (PDUs) using theHashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in InternationalStandards Organization (ISO) 10589, with extensions to supportInternet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords.
This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.

RFC 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 3569 An Overview of Source-Specific Multicast (SSM)

Authors: S. Bhattacharyya, Ed..

Date: July 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3569

The purpose of this document is to provide an overview ofSource-Specific Multicast (SSM) and issues related to its deployment.It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models.

RFC 3570 Content Internetworking (CDI) Scenarios

Authors: P. Rzewski, M. Day, D. Gilletti.

Date: July 2003

Formats: txt json html

Obsoleted by: RFC 6770

Status: INFORMATIONAL

DOI: 10.17487/RFC 3570

In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals.

RFC 3571 Framework Policy Information Base for Usage Feedback

Authors: D. Rawlins, A. Kulkarni, K. Ho Chan, M. Bokaemper, D. Dutt.

Date: August 2003

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 3571

This document describes a portion of the Policy Information Base(PIB) to control policy usage collection and reporting in a device.
The provisioning classes specified here allow a Policy Decision Point(PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported.
This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected.

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 3573 Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)

Authors: I. Goyret.

Date: July 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3573

The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network.
One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re- establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls.
The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled.
This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold.

RFC 3574 Transition Scenarios for 3GPP Networks

Authors: J. Soininen, Ed..

Date: August 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3574

This document describes different scenarios in Third GenerationPartnership Project (3GPP) defined packet network, i.e., GeneralPacket Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study.

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 3576 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)

Authors: M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba.

Date: July 2003

Formats: txt html json

Obsoleted by: RFC 5176

Status: INFORMATIONAL

DOI: 10.17487/RFC 3576

This document describes a currently deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session.

RFC 3577 Introduction to the Remote Monitoring (RMON) Family of MIB Modules

Authors: S. Waldbusser, R. Cole, C. Kalbfleisch, D. Romascanu.

Date: August 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3577

The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another.

RFC 3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)

Authors: G. Camarillo, A. B. Roach, J. Peterson, L. Ong.

Date: August 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3578

This document describes a way to map Integrated Services DigitalNetwork User Part (ISUP) overlap signalling to Session InitiationProtocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).

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 3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

Authors: J. Rosenberg, H. Schulzrinne.

Date: August 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3581

The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated.

RFC 3582 Goals for IPv6 Site-Multihoming Architectures

Authors: J. Abley, B. Black, V. Gill.

Date: August 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3582

This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here.

RFC 3583 Requirements of a Quality of Service (QoS) Solution for Mobile IP

Authors: H. Chaskar, Ed..

Date: September 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3583

Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet.However, it is also required to provide proper Quality of Service(QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP.

RFC 3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

Authors: R. Frye, D. Levi, S. Routhier, B. Wijnen.

Date: August 2003

Formats: txt json html

Obsoletes: RFC 2576

Also: BCP 0074

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3584

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework,(SNMPv3), version 2 of the Internet-standard Network ManagementFramework (SNMPv2), and the original Internet-standard NetworkManagement Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576.

RFC 3585 IPsec Configuration Policy Information Model

Authors: J. Jason, L. Rafalow, E. Vyncke.

Date: August 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3585

This document presents an object-oriented information model of IPSecurity (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints. The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange protocol (IKE). Other key exchange protocols could easily be added to the information model by a simple extension. Further extensions can further be added easily due to the object-oriented nature of the model.
This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the PolicyCore Information Model Extensions (PCIMe).

RFC 3586 IP Security Policy (IPSP) Requirements

Authors: M. Blaze, A. Keromytis, M. Richardson, L. Sanchez.

Date: August 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3586

This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IPSecurity properties. This document highlights such architectural components and presents their functional requirements.

RFC 3587 IPv6 Global Unicast Address Format

Authors: R. Hinden, S. Deering, E. Nordmark.

Date: August 2003

Formats: txt html json

Obsoletes: RFC 2374

Status: INFORMATIONAL

DOI: 10.17487/RFC 3587

This document obsoletes RFC 2374, "An IPv6 Aggregatable GlobalUnicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next LevelAggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic.

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 3589 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5

Authors: J. Loughney.

Date: September 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3589

This document describes the IANA's allocation of a block of DiameterCommand Codes for the Third Generation Partnership Project (3GPP)Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification.

RFC 3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol

Authors: B. Haberman.

Date: September 2003

Formats: txt json html

Updates: RFC 2710

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3590

It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages.

RFC 3591 Definitions of Managed Objects for the Optical Interface Type

Authors: H-K. Lam, M. Stewart, A. Huynh.

Date: September 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3591

This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP- based internets. In particular, it defines objects for managingOptical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T RecommendationG.872.
The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface.

RFC 3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type

Authors: K. Tesink.

Date: September 2003

Formats: txt html json

Obsoletes: RFC 2558

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3592

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types.
This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause.

RFC 3593 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals

Authors: K. Tesink, Ed..

Date: September 2003

Formats: txt html json

Obsoletes: RFC 2493

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3593

This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals.
This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause.

RFC 3594 PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option

Authors: P. Duffy.

Date: September 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3594

This document defines a new sub-option for the DHCP CableLabs ClientConfiguration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets).

RFC 3595 Textual Conventions for IPv6 Flow Label

Authors: B. Wijnen.

Date: September 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3595

This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions(TCs) will be imported and used in MIB modules that would otherwise define their own representations.

RFC 3596 DNS Extensions to Support IP Version 6

Authors: S. Thomson, C. Huitema, V. Ksinant, M. Souissi.

Date: October 2003

Formats: txt html json

Obsoletes: RFC 3152, RFC 1886

Also: STD 0088

Status: INTERNET STANDARD

DOI: 10.17487/RFC 3596

This document defines the changes that need to be made to the DomainName System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a 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 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 3598 Sieve Email Filtering -- Subaddress Extension

Authors: K. Murchison.

Date: September 2003

Formats: txt json html

Obsoleted by: RFC 5233

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3598

On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses.This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address.

RFC 3599 Request for Comments Summary RFC Numbers 3500-3599

Authors: S. Ginoza.

Date: December 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3599

This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599. This is a status report on these RFCs

RFC 3600 Internet Official Protocol Standards

Authors: J. Reynolds, Ed., S. Ginoza, Ed..

Date: November 2003

Formats: txt json html

Obsoletes: RFC 3300

Obsoleted by: RFC 3700

Status: HISTORIC

DOI: 10.17487/RFC 3600

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.

RFC 3601 Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses

Authors: C. Allocchio.

Date: September 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3601

This memo describes the full set of notations needed to represent a text string in a Dial Sequence. A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional "actions" (such as "wait for dialtone", "pause for N secs", etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply.

RFC 3602 The AES-CBC Cipher Algorithm and Its Use with IPsec

Authors: S. Frankel, R. Glenn, S. Kelly.

Date: September 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3602

This document describes the use of the Advanced Encryption Standard(AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).

RFC 3603 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture

Authors: W. Marshall, Ed., F. Andreasen, Ed..

Date: October 2003

Formats: txt html json

Obsoleted by: RFC 5503

Status: INFORMATIONAL

DOI: 10.17487/RFC 3603

In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable DistributedCall Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.

RFC 3604 Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3)

Authors: H. Khosravi, G. Kullgren, S. Shew, J. Sadler, A. Watanabe.

Date: October 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3604

This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification.

RFC 3605 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)

Authors: C. Huitema.

Date: October 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3605

The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.

RFC 3606 Definitions of Supplemental Managed Objects for ATM Interface

Authors: F. Ly, M. Noto, A. Smith, E. Spiegel, K. Tesink.

Date: November 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3606

This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, theATM-MIB, to provide additional support for the management of ATMSwitched Virtual Connections (SVCs) and ATM Permanent VirtualConnections (PVCs).

RFC 3607 Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool

Authors: M. Leech.

Date: September 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3607

This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences.

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 3609 Tracing Requirements for Generic Tunnels

Authors: R. Bonica, K. Kompella, D. Meyer.

Date: September 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3609

This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding.
The generic route-tracing application, specified herein, supports a superset of the functionality that "traceroute" currently offers.Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by anIP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path.

RFC 3610 Counter with CBC-MAC (CCM)

Authors: D. Whiting, R. Housley, N. Ferguson.

Date: September 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3610

Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES).

RFC 3611 RTP Control Protocol Extended Reports (RTCP XR)

Authors: T. Friedman, Ed., R. Caceres, Ed., A. Clark, Ed..

Date: November 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3611

This document defines the Extended Report (XR) packet type for theRTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the SessionDescription Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used byRTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics(MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.

RFC 3612 Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP)

Authors: A. Farrel.

Date: September 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3612

This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212,"Constraint-Based LSP Setup Using LDP".

RFC 3613 Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE)

Authors: R. Morgan, K. Hazelton.

Date: October 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3613

This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE).This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates.

RFC 3614 A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG)

Authors: J. Smith.

Date: September 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3614

This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG 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 MPEG.

RFC 3615 A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging

Authors: J. Gustin, A. Goyens.

Date: September 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3615

This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.

RFC 3616 A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA)

Authors: F. Bellifemine, I. Constantinescu, S. Willmott.

Date: September 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3616

This document describes a Uniform Resource Name NamespaceIdentification (URN NID) for the Foundation for Intelligent PhysicalAgents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology.

RFC 3617 Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)

Authors: E. Lear.

Date: October 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3617

The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time.While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.

RFC 3618 Multicast Source Discovery Protocol (MSDP)

Authors: B. Fenner, Ed., D. Meyer, Ed..

Date: October 2003

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3618

The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent MulticastSparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend onRPs in other domains. This document reflects existing MSDP implementations.

RFC 3619 Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1

Authors: S. Shah, M. Yip.

Date: October 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3619

This document describes the Ethernet Automatic Protection Switching(EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided bySONET rings, at a lower cost and with fewer constraints (e.g., ring size).

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 3621 Power Ethernet MIB

Authors: A. Berger, D. Romascanu.

Date: December 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3621

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This document proposes an extension to the Ethernet-like InterfacesMIB with a set of objects for managing Power Sourcing Equipment(PSE).

RFC 3622 A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project

Authors: M. Mealling.

Date: February 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3622

This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.

RFC 3623 Graceful OSPF Restart

Authors: J. Moy, P. Pillay-Esnault, A. Lindem.

Date: November 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3623

This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as itsOSPF software is restarted. This is called "graceful restart" or"non-stop forwarding". A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented.

RFC 3624 The Media Gateway Control Protocol (MGCP) Bulk Audit Package

Authors: B. Foster, D. Auerbach, F. Andreasen.

Date: November 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3624

The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints.It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints.

RFC 3625 The QCP File Format and Media Types for Speech Data

Authors: R. Gellens, H. Garudadri.

Date: September 2003

Formats: txt json html

Updates: RFC 3555

Status: INFORMATIONAL

DOI: 10.17487/RFC 3625

RFC 2658 specifies the streaming format for 3GPP2 13K vocoder (HighRate Speech Service Option 17 for Wideband Spread SpectrumCommunications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format. Many implementations have been using the "QCP" file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder(EVRC) and Selectable Mode Vocoders (SMV) data. (For example,Eudora(r), QuickTime(r), and cmda2000(r) handsets).
This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types forEVRC and SMV (respectively) data stored in this format.

RFC 3626 Optimized Link State Routing Protocol (OLSR)

Authors: T. Clausen, Ed., P. Jacquet, Ed..

Date: October 2003

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3626

This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.

RFC 3627 Use of /127 Prefix Length Between Routers Considered Harmful

Authors: P. Savola.

Date: September 2003

Formats: txt html json

Obsoleted by: RFC 6547

Status: HISTORIC

DOI: 10.17487/RFC 3627

In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers.Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.

RFC 3628 Policy Requirements for Time-Stamping Authorities (TSAs)

Authors: D. Pinkas, N. Pope, J. Ross.

Date: November 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3628

This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document.

RFC 3629 UTF-8, a transformation format of ISO 10646

Authors: F. Yergeau.

Date: November 2003

Formats: txt json html

Obsoletes: RFC 2279

Also: STD 0063

Status: INTERNET STANDARD

DOI: 10.17487/RFC 3629

ISO/IEC 10646-1 defines a large character set called the UniversalCharacter Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.This memo obsoletes and replaces RFC 2279.

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 3631 Security Mechanisms for the Internet

Authors: S. Bellovin, Ed., J. Schiller, Ed., C. Kaufman, Ed..

Date: December 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3631

Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself.However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.

RFC 3632 VeriSign Registry Registrar Protocol (RRP) Version 2.0.0

Authors: S. Hollenbeck, S. Veeramachaneni, S. Yalamanchilli.

Date: November 2003

Formats: txt html json

Updates: RFC 2832

Status: INFORMATIONAL

DOI: 10.17487/RFC 3632

This document updates version 1.1.0 of the Network Solutions Inc.(NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of theVeriSign Registry Registrar Protocol.

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 3634 Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option

Authors: K. Luehrs, R. Woundy, J. Bevilacqua, N. Davoust.

Date: December 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3634

This document defines a new sub-option for the CableLabs ClientConfiguration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center(KDC) servers.

RFC 3635 Definitions of Managed Objects for the Ethernet-like Interface Types

Authors: J. Flick.

Date: September 2003

Formats: txt json html

Obsoletes: RFC 2665

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3635

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.

RFC 3636 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)

Authors: J. Flick.

Date: September 2003

Formats: txt html json

Obsoletes: RFC 2668, RFC 1515

Obsoleted by: RFC 4836

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3636

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing IEEE 802.3 MediumAttachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515.

RFC 3637 Definitions of Managed Objects for the Ethernet WAN Interface Sublayer

Authors: C.M. Heard, Ed..

Date: September 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3637

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing theEthernet Wide Area Network (WAN) Interface Sublayer (WIS).
The MIB module defined in this memo is an extension of theSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Interface MIB and is implemented in conjunction with it and with theEthernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB.

RFC 3638 Applicability Statement for Reclassification of RFC 1643 to Historic Status

Authors: J. Flick, C. M. Heard.

Date: September 2003

Formats: txt json html

Obsoletes: RFC 1643

Status: INFORMATIONAL

DOI: 10.17487/RFC 3638

This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation.

RFC 3639 Considerations on the use of a Service Identifier in Packet Headers

Authors: M. St. Johns, Ed., G. Huston, Ed., IAB.

Date: October 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3639

This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number.

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 3642 Common Elements of Generic String Encoding Rules (GSER) Encodings

Authors: S. Legg.

Date: October 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3642

The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes.

RFC 3643 Fibre Channel (FC) Frame Encapsulation

Authors: R. Weber, M. Rajagopal, F. Travostino, M. O'Donnell, C. Monia, M. Merhar.

Date: December 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3643

This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.

RFC 3644 Policy Quality of Service (QoS) Information Model

Authors: Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, B. Moore.

Date: November 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3644

This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies.This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.

RFC 3645 Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)

Authors: S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. Hall.

Date: October 2003

Formats: txt html json

Updates: RFC 2845

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3645

The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security ServiceApplication Program Interface (GSS-API) (RFC2743). This document updates RFC 2845.

RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Authors: R. Droms, Ed..

Date: December 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3646

This document describes Dynamic Host Configuration Protocol for IPv6(DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.

RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework

Authors: S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu.

Date: November 2003

Formats: txt json html

Obsoletes: RFC 2527

Status: INFORMATIONAL

DOI: 10.17487/RFC 3647

This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527.

RFC 3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol

Authors: J. Whitehead, J. Reschke, Ed..

Date: December 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3648

This specification extends the Web Distributed Authoring andVersioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.

RFC 3649 HighSpeed TCP for Large Congestion Windows

Authors: S. Floyd.

Date: December 2003

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3649

The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals.
This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the currentStandard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address this limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.

RFC 3650 Handle System Overview

Authors: S. Sun, L. Lannom, B. Boesch.

Date: November 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3650

This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. TheHandle System is a general-purpose global name service that allows secured name resolution and administration over networks such as theInternet. The Handle System manages handles, which are unique names for digital objects and other Internet resources.

RFC 3651 Handle System Namespace and Service Definition

Authors: S. Sun, S. Reilly, L. Lannom.

Date: November 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3651

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the publicInternet. This document provides a detailed description of theHandle System namespace, and its data, service, and operation models.The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by theHandle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.

RFC 3652 Handle System Protocol (ver 2.1) Specification

Authors: S. Sun, S. Reilly, L. Lannom, J. Petrone.

Date: November 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3652

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the publicInternet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle.It also defines the messages exchanged between the client and server for any handle operation.

RFC 3653 XML-Signature XPath Filter 2.0

Authors: J. Boyer, M. Hughes, J. Reagle.

Date: December 2003

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3653

XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles.
This document is the W3C XML Signature XPath-Filter 2.0Recommendation. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as aW3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

RFC 3654 Requirements for Separation of IP Control and Forwarding

Authors: H. Khosravi, Ed., T. Anderson, Ed..

Date: November 2003

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3654

This document introduces the Forwarding and Control ElementSeparation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.

RFC 3655 Redefinition of DNS Authenticated Data (AD) bit

Authors: B. Wellington, O. Gudmundsson.

Date: November 2003

Formats: txt html json

Obsoleted by: RFC 4033, RFC 4034, RFC 4035

Updates: RFC 2535

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3655

This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.

RFC 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 3657 Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)

Authors: S. Moriai, A. Kato.

Date: January 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3657

This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic MessageSyntax (CMS).

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 3659 Extensions to FTP

Authors: P. Hethmon.

Date: March 2007

Formats: txt html json

Updates: RFC 0959

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3659

This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure.

RFC 3660 Basic Media Gateway Control Protocol (MGCP) Packages

Authors: B. Foster, F. Andreasen.

Date: December 2003

Formats: txt html json

Updates: RFC 2705

Status: INFORMATIONAL

DOI: 10.17487/RFC 3660

This document provides a basic set of Media Gateway Control Protocol(MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (DualTone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.

RFC 3661 Media Gateway Control Protocol (MGCP) Return Code Usage

Authors: B. Foster, C. Sivachelvan.

Date: December 2003

Formats: txt html json

Updates: RFC 3435

Status: INFORMATIONAL

DOI: 10.17487/RFC 3661

This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP)Version 1.0. Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that theCall Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency.

RFC 3662 A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services

Authors: R. Bless, K. Nichols, K. Wehrle.

Date: December 2003

Formats: txt json html

Obsoleted by: RFC 8622

Status: INFORMATIONAL

DOI: 10.17487/RFC 3662

This document proposes a differentiated services per-domain behavior(PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best- effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.

RFC 3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)

Authors: A. Newton.

Date: December 2003

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3663

Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP)Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available.

RFC 3664 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)

Authors: P. Hoffman.

Date: January 2004

Formats: txt html json

Obsoleted by: RFC 4434

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3664

Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard(AES). This document describes such an algorithm, called AES-XCBC-PRF-128.

RFC 3665 Session Initiation Protocol (SIP) Basic Call Flow Examples

Authors: A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers.

Date: December 2003

Formats: txt html json

Also: BCP 0075

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3665

This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents andClients, SIP Proxy and Redirect Servers. Scenarios include SIPRegistration and SIP session establishment. Call flow diagrams and message details are shown.

RFC 3666 Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows

Authors: A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers.

Date: December 2003

Formats: txt json html

Also: BCP 0076

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3666

This document contains best current practice examples of SessionInitiation Protocol (SIP) call flows showing interworking with thePublic Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways.Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP.PSTN telephony protocols are illustrated using ISDN (IntegratedServices Digital Network), ISUP (ISDN User Part), and FGB (FeatureGroup B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown.

RFC 3667 IETF Rights in Contributions

Authors: S. Bradner.

Date: February 2004

Formats: txt json html

Obsoleted by: RFC 3978

Updates: RFC 2026

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3667

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC2026.

RFC 3668 Intellectual Property Rights in IETF Technology

Authors: S. Bradner.

Date: February 2004

Formats: txt html json

Obsoleted by: RFC 3979

Updates: RFC 2026, RFC 2028

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3668

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet.This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 ofRFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC2028, for all purposes, including reference [2] in RFC 2418.

RFC 3669 Guidelines for Working Groups on Intellectual Property Issues

Authors: S. Brim.

Date: February 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3669

This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF.

RFC 3670 Information Model for Describing Network Device QoS Datapath Mechanisms

Authors: B. Moore, D. Durham, J. Strassner, A. Westerinen, W. Weiss.

Date: January 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3670

The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services.
This document should be used with the QoS Policy Information Model(QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices.Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices.
This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository.

RFC 3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP)

Authors: K. Zeilenga.

Date: December 2003

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3671

X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory AccessProtocol). This document provides schema definitions for collective attributes for use in LDAP.

RFC 3672 Subentries in the Lightweight Directory Access Protocol (LDAP)

Authors: K. Zeilenga.

Date: December 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3672

In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with theLightweight Directory Access Protocol (LDAP).

RFC 3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes

Authors: K. Zeilenga.

Date: December 2003

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3673

The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes.

RFC 3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP)

Authors: K. Zeilenga.

Date: December 2003

Formats: txt html json

Obsoleted by: RFC 4512

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3674

The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms.

RFC 3675 .sex Considered Dangerous

Authors: D. Eastlake 3rd.

Date: February 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3675

Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.

RFC 3676 The Text/Plain Format and DelSp Parameters

Authors: R. Gellens.

Date: February 2004

Formats: txt json html

Obsoletes: RFC 2646

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3676

This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting.
This document supersedes the one specified in RFC 2646, "TheText/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely.

RFC 3677 IETF ISOC Board of Trustee Appointment Procedures

Authors: L. Daigle, Ed., Internet Architecture Board.

Date: December 2003

Formats: txt json html

Also: BCP 0077

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3677

This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.

RFC 3678 Socket Interface Extensions for Multicast Source Filters

Authors: D. Thaler, B. Fenner, B. Quinn.

Date: January 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3678

The Internet Group Management Protocol (IGMPv3) for IPv4 and theMulticast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications.
This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.

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 3681 Delegation of E.F.F.3.IP6.ARPA

Authors: R. Bush, R. Fink.

Date: January 2004

Formats: txt html json

Also: BCP 0080

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3681

This document discusses the need for delegation of theE.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for6bone addresses, and makes specific recommendations for the process needed to accomplish this.

RFC 3682 The Generalized TTL Security Mechanism (GTSM)

Authors: V. Gill, J. Heasley, D. Meyer.

Date: February 2004

Formats: txt json html

Obsoleted by: RFC 5082

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3682

The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),Bidirectional Forwarding Detection, and Label Distribution Protocol(LDP) (RFC 3036). While the Generalized TTL Security Mechanism(GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis.

RFC 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 3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions

Authors: C. Daboo.

Date: February 2004

Formats: txt html json

Obsoleted by: RFC 5235

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3685

The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests.

RFC 3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)

Authors: R. Housley.

Date: January 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3686

This document describes the use of Advanced Encryption Standard (AES)Counter Mode, with an explicit initialization vector, as an IPsecEncapsulating Security Payload (ESP) confidentiality mechanism.

RFC 3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules

Authors: S. Legg.

Date: February 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3687

The syntaxes of attributes in a Lightweight Directory Access Protocol(LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes.Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax.

RFC 3688 The IETF XML Registry

Authors: M. Mealling.

Date: January 2004

Formats: txt html json

Also: BCP 0081

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3688

This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, andResource Description Framework (RDF) Schemas.

RFC 3689 General Requirements for Emergency Telecommunication Service (ETS)

Authors: K. Carlberg, R. Atkinson.

Date: February 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3689

This document presents a list of general requirements in support ofEmergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s).

RFC 3690 IP Telephony Requirements for Emergency Telecommunication Service (ETS)

Authors: K. Carlberg, R. Atkinson.

Date: February 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3690

This document presents a list of requirements in support of EmergencyTelecommunications Service (ETS) within the context of IP telephony.It is an extension to the general requirements presented in RFC 3689.Solutions to these requirements are not presented in this document.

RFC 3691 Internet Message Access Protocol (IMAP) UNSELECT command

Authors: A. Melnikov.

Date: February 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3691

This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version4 (IMAP4) session without expunging it. Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While IMAP4 provides this functionality (via a SELECT command with a nonexistent mailbox name or reselecting the same mailbox with EXAMINE command), a more clean solution is desirable.

RFC 3692 Assigning Experimental and Testing Numbers Considered Useful

Authors: T. Narten.

Date: January 2004

Formats: txt json html

Updates: RFC 2434

Also: BCP 0082

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3692

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.

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 3695 Compact Forward Error Correction (FEC) Schemes

Authors: M. Luby, L. Vicisano.

Date: February 2004

Formats: txt html json

Obsoleted by: RFC 5445

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3695

This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FECPayload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead.
This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block.

RFC 3696 Application Techniques for Checking and Transformation of Names

Authors: J. Klensin.

Date: February 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3696

Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards.

RFC 3697 IPv6 Flow Label Specification

Authors: J. Rajahalme, A. Conta, B. Carpenter, S. Deering.

Date: March 2004

Formats: txt json html

Obsoleted by: RFC 6437

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3697

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods.Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document.
The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.

RFC 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 3700 Internet Official Protocol Standards

Authors: J. Reynolds, Ed., S. Ginoza, Ed..

Date: July 2004

Formats: txt html json

Obsoletes: RFC 3600

Obsoleted by: RFC 5000

Status: HISTORIC

DOI: 10.17487/RFC 3700

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.

RFC 3701 6bone (IPv6 Testing Address Allocation) Phaseout

Authors: R. Fink, R. Hinden.

Date: March 2004

Formats: txt html json

Obsoletes: RFC 2471

Status: INFORMATIONAL

DOI: 10.17487/RFC 3701

The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this.
This document obsoletes RFC 2471, "IPv6 Testing Address Allocation",December, 1998. RFC 2471 will become historic.

RFC 3702 Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP)

Authors: J. Loughney, G. Camarillo.

Date: February 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3702

As Session Initiation Protocol (SIP) services are deployed on theInternet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work.

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 3705 High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals

Authors: B. Ray, R. Abbi.

Date: February 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3705

This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856.

RFC 3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers

Authors: G. Huang, S. Beaulieu, D. Rochefort.

Date: February 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3706

This document describes the method detecting a dead Internet KeyExchange (IKE) peer that is presently in use by a number of vendors.The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources.

RFC 3707 Cross Registry Internet Service Protocol (CRISP) Requirements

Authors: A. Newton.

Date: February 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3707

Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries.

RFC 3708 Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions

Authors: E. Blanton, M. Allman.

Date: February 2004

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3708

TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate SelectiveAcknowledgement (DSACKs) and Duplicate Transmission Sequence Number(TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications.

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 3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services

Authors: P. Fleming, I. McDonald.

Date: February 2004

Formats: txt json html

Obsoleted by: RFC 7612

Status: INFORMATIONAL

DOI: 10.17487/RFC 3712

This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that supportLightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of InternetPrinting Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759).

RFC 3713 A Description of the Camellia Encryption Algorithm

Authors: M. Matsui, J. Nakajima, S. Moriai.

Date: April 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3713

This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part.

RFC 3714 IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet

Authors: S. Floyd, Ed., J. Kempf, Ed..

Date: March 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3714

This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet.These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service(QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice overInternet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in theInternet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic.

RFC 3715 IPsec-Network Address Translation (NAT) Compatibility Requirements

Authors: B. Aboba, W. Dixon.

Date: March 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3715

This document describes known incompatibilities between NetworkAddress Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment ofIPsec in one of its principal uses.

RFC 3716 IETF in the Large: Administration and Execution

Authors: IAB Advisory Committee.

Date: March 2004

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 3716

In the fall of 2003, the IETF Chair and the IAB Chair formed an IABAdvisory Committee (AdvComm), with a mandate to review the existingIETF administrative structure and relationships (RFC Editor, IETFSecretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF.The AdvComm mandate did not include the standards process itself.
This memo documents the AdvComm's findings and proposals.

RFC 3717 IP over Optical Networks: A Framework

Authors: B. Rajagopalan, J. Luciani, D. Awduche.

Date: March 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3717

The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as "IP over optical networks").

RFC 3718 A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access

Authors: R. McGowan.

Date: February 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3718

This memo describes various internal workings of the UnicodeConsortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding & standardization processes.

RFC 3719 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)

Authors: J. Parker, Ed..

Date: February 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3719

This document discusses a number of differences between theIntermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today.These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic.

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 3722 String Profile for Internet Small Computer Systems Interface (iSCSI) Names

Authors: M. Bakke.

Date: April 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3722

This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world.
The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network.The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared.

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 3724 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture

Authors: J. Kempf, Ed., R. Austein, Ed., IAB.

Date: March 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3724

The end-to-end principle is the core architectural guideline of theInternet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends.

RFC 3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)

Authors: J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo.

Date: April 2004

Formats: txt html json

Also: BCP 0085

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3725

Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control.

RFC 3726 Requirements for Signaling Protocols

Authors: M. Brunner, Ed..

Date: April 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3726

This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined.For example, signaling for label distribution in Multiprotocol LabelSwitching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility.

RFC 3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules

Authors: S. Legg.

Date: February 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3727

This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One(ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules.

RFC 3728 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)

Authors: B. Ray, R. Abbi.

Date: February 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3728

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High SpeedDigital Subscriber Line (VDSL) interfaces.

RFC 3729 Application Performance Measurement MIB

Authors: S. Waldbusser.

Date: March 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3729

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 measuring the application performance as experienced by end-users.

RFC 3730 Extensible Provisioning Protocol (EPP)

Authors: S. Hollenbeck.

Date: March 2004

Formats: txt html json

Obsoleted by: RFC 4930

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3730

This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration.

RFC 3731 Extensible Provisioning Protocol (EPP) Domain Name Mapping

Authors: S. Hollenbeck.

Date: March 2004

Formats: txt html json

Obsoleted by: RFC 4931

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3731

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.

RFC 3732 Extensible Provisioning Protocol (EPP) Host Mapping

Authors: S. Hollenbeck.

Date: March 2004

Formats: txt json html

Obsoleted by: RFC 4932

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3732

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.

RFC 3733 Extensible Provisioning Protocol (EPP) Contact Mapping

Authors: S. Hollenbeck.

Date: March 2004

Formats: txt json html

Obsoleted by: RFC 4933

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3733

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts.

RFC 3734 Extensible Provisioning Protocol (EPP) Transport Over TCP

Authors: S. Hollenbeck.

Date: March 2004

Formats: txt html json

Obsoleted by: RFC 4934

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3734

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server.

RFC 3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP)

Authors: S. Hollenbeck.

Date: March 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3735

The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities.

RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6

Authors: R. Droms.

Date: April 2004

Formats: txt json html

Obsoleted by: RFC 8415

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3736

Stateless Dynamic Host Configuration Protocol service for IPv6(DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP.

RFC 3737 IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules

Authors: B. Wijnen, A. Bierman.

Date: April 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3737

This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring(rmon) root. This memo also documents the currently assigned values.

RFC 3738 Wave and Equation Based Rate Control (WEBRC) Building Block

Authors: M. Luby, V. Goyal.

Date: April 2004

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3738

This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender.Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender.

RFC 3739 Internet X.509 Public Key Infrastructure: Qualified Certificates Profile

Authors: S. Santesson, M. Nystrom, T. Polk.

Date: March 2004

Formats: txt html json

Obsoletes: RFC 3039

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3739

This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons.
The profile defines specific conventions for certificates that are qualified within a defined legal framework, named QualifiedCertificates. However, the profile does not define any legal requirements for such Qualified Certificates.
The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements. The profile is however not limited to QualifiedCertificates and further profiling may facilitate specific local needs.

RFC 3740 The Multicast Group Security Architecture

Authors: T. Hardjono, B. Weis.

Date: March 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3740

This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast SecurityReference Framework, and proceeds to identify the security services that may be part of a secure multicast solution.

RFC 3741 Exclusive XML Canonicalization, Version 1.0

Authors: J. Boyer, D. Eastlake 3rd, J. Reagle.

Date: March 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3741

Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the"xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization.

RFC 3742 Limited Slow-Start for TCP with Large Congestion Windows

Authors: S. Floyd.

Date: March 2004

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3742

This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender'sMAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describesLimited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance forTCP connections with large congestion windows.

RFC 3743 Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean

Authors: K. Konishi, K. Huang, H. Qian, Y. Ko.

Date: April 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3743

Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration.
The IETF Standards for Internationalized Domain Names, known as"IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts.

RFC 3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol

Authors: G. Clemm, J. Reschke, E. Sedlar, J. Whitehead.

Date: May 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3744

This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to theWebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such asHyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names.

RFC 3745 MIME Type Registrations for JPEG 2000 (ISO/IEC 15444)

Authors: D. Singer, R. Clark, D. Lee.

Date: April 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3745

This document serves to register and document the standard MIME types associated with the ISO/IEC 15444 standards, commonly known as JPEG2000 (Joint Photographic Experts Group).

RFC 3746 Forwarding and Control Element Separation (ForCES) Framework

Authors: L. Yang, R. Dantu, T. Anderson, R. Gopal.

Date: April 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3746

This document defines the architectural framework for the ForCES(Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions.

RFC 3747 The Differentiated Services Configuration MIB

Authors: H. Hazewinkel, Ed., D. Partain, Ed..

Date: April 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3747

This memo describes a MIB module that provides a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB.

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 3750 Unmanaged Networks IPv6 Transition Scenarios

Authors: C. Huitema, R. Austein, S. Satapati, R. van der Pol.

Date: April 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3750

This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged network", which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6.

RFC 3751 Omniscience Protocol Requirements

Authors: S. Bradner.

Date: 1 April 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3751

There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, theOmniscience Protocol, that could be used to enable such efforts.

RFC 3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios

Authors: A. Barbir, E. Burger, R. Chen, S. McHenry, H. Orman, R. Penno.

Date: April 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3752

This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses.

RFC 3753 Mobility Related Terminology

Authors: J. Manner, Ed., M. Kojo, Ed..

Date: June 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3753

There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in theSeamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology.

RFC 3754 IP Multicast in Differentiated Services (DS) Networks

Authors: R. Bless, K. Wehrle.

Date: April 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3754

This document discusses the problems of IP Multicast use inDifferentiated Services (DS) networks, expanding on the discussion inRFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results.

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 3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats

Authors: P. Nikander, Ed., J. Kempf, E. Nordmark.

Date: May 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3756

The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsecAuthentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery.

RFC 3757 Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag

Authors: O. Kolkman, J. Schlyter, E. Lewis.

Date: April 2004

Formats: txt html json

Obsoleted by: RFC 4033, RFC 4034, RFC 4035

Updates: RFC 3755, RFC 2535

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3757

With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the DomainName System KEY (DNSKEY) resource record set. A flag bit in theDNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC2535 and RFC 3755.

RFC 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension

Authors: R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad.

Date: May 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3758

This memo describes an extension to the Stream Control TransmissionProtocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism.

RFC 3759 RObust Header Compression (ROHC): Terminology and Channel Mapping Examples

Authors: L-E. Jonsson.

Date: April 2004

Formats: txt json html

Updates: RFC 3095

Status: INFORMATIONAL

DOI: 10.17487/RFC 3759

This document aims to clarify terms and concepts presented in RFC3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues.

RFC 3760 Securely Available Credentials (SACRED) - Credential Server Framework

Authors: D. Gustafson, M. Just, M. Nystrom.

Date: April 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3760

As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework.

RFC 3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)

Authors: P. Faltstrom, M. Mealling.

Date: April 2004

Formats: txt json html

Obsoletes: RFC 2916

Obsoleted by: RFC 6116, RFC 6117

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3761

This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the DynamicDelegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401.

RFC 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 3763 One-way Active Measurement Protocol (OWAMP) Requirements

Authors: S. Shalunov, B. Teitelbaum.

Date: April 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3763

With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol(OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss.

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 3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control

Authors: G. Huston.

Date: April 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3765

This document describes the use of a scope control Border GatewayProtocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections.

RFC 3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys

Authors: H. Orman, P. Hoffman.

Date: April 2004

Formats: txt html json

Also: BCP 0086

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3766

Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage.
While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange.

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 3768 Virtual Router Redundancy Protocol (VRRP)

Authors: R. Hinden, Ed..

Date: April 2004

Formats: txt json html

Obsoletes: RFC 2338

Obsoleted by: RFC 5798

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3768

This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on aLAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.

RFC 3769 Requirements for IPv6 Prefix Delegation

Authors: S. Miyakawa, R. Droms.

Date: June 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3769

This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site").

RFC 3770 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)

Authors: R. Housley, T. Moore.

Date: May 2004

Formats: txt json html

Obsoleted by: RFC 4334

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3770

This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs).

RFC 3771 The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message

Authors: R. Harrison, K. Zeilenga.

Date: April 2004

Formats: txt json html

Obsoleted by: RFC 4511, RFC 4510

Updates: RFC 2251

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3771

This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). TheIntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAPExtendedRequest and ExtendedResponse to define new single- request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information.

RFC 3772 Point-to-Point Protocol (PPP) Vendor Protocol

Authors: J. Carlson, R. Winslow.

Date: May 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3772

The Point-to-Point Protocol (PPP) defines a Link Control Protocol(LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor- specific Network, Authentication, and Control Protocols.

RFC 3773 High-Level Requirements for Internet Voice Mail

Authors: E. Candell.

Date: June 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3773

This document describes the high-level requirements for InternetVoice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for InternetMail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment.This document does not include goals that were met fully by VPIM version 2.

RFC 3774 IETF Problem Statement

Authors: E. Davies, Ed..

Date: May 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3774

This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community.
The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections.

RFC 3775 Mobility Support in IPv6

Authors: D. Johnson, C. Perkins, J. Arkko.

Date: June 2004

Formats: txt json html

Obsoleted by: RFC 6275

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3775

This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation,Mobile IPv6 defines a new IPv6 protocol and a new destination option.All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes.

RFC 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 3778 The application/pdf Media Type

Authors: E. Taft, J. Pravetz, S. Zilles, L. Masinter.

Date: May 2004

Formats: txt json html

Obsoleted by: RFC 8118

Status: INFORMATIONAL

DOI: 10.17487/RFC 3778

PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of thePDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'.

RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers

Authors: C. Lynn, S. Kent, K. Seo.

Date: June 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3779

This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions.

RFC 3780 SMIng - Next Generation Structure of Management Information

Authors: F. Strauss, J. Schoenwaelder.

Date: May 2004

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3780

This memo defines the base SMIng (Structure of ManagementInformation, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP.

RFC 3781 Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)

Authors: F. Strauss, J. Schoenwaelder.

Date: May 2004

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3781

SMIng (Structure of Management Information, Next Generation)(RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework.

RFC 3782 The NewReno Modification to TCP's Fast Recovery Algorithm

Authors: S. Floyd, T. Henderson, A. Gurtov.

Date: April 2004

Formats: txt html json

Obsoletes: RFC 2582

Obsoleted by: RFC 6582

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3782

The purpose of this document is to advance NewReno TCP's FastRetransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status.
The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewRenoTCP.

RFC 3783 Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI

Authors: M. Chadalapaka, R. Elliott.

Date: May 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3783

Internet Small Computer Systems Interface (iSCSI) is a Small ComputerSystems Interface (SCSI) transport protocol designed to run on top ofTCP. The iSCSI session abstraction is equivalent to the classic SCSI"I_T nexus", which represents the logical relationship between anInitiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI.

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 3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric

Authors: F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx, T. Telkamp.

Date: May 2004

Formats: txt json html

Also: BCP 0087

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3785

This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint BasedRouting of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to performConstraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices.

RFC 3786 Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit

Authors: A. Hermelin, S. Previdi, M. Shand.

Date: May 2004

Formats: txt html json

Obsoleted by: RFC 5311

Status: INFORMATIONAL

DOI: 10.17487/RFC 3786

This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers.

RFC 3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS)

Authors: J. Parker, Ed..

Date: May 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3787

This document discusses a number of differences between theIntermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice.

RFC 3788 Security Considerations for Signaling Transport (SIGTRAN) Protocols

Authors: J. Loughney, M. Tuexen, Ed., J. Pastor-Balbas.

Date: June 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3788

This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional.

RFC 3789 Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents

Authors: P. Nesser, II, A. Bergstrom, Ed..

Date: June 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3789

This document is a general overview and introduction to the v6opsIETF workgroup project of documenting all usage of IPv4 addresses inIETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results.

RFC 3790 Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents

Authors: C. Mickles, Ed., P. Nesser, II.

Date: June 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3790

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.

RFC 3791 Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents

Authors: C. Olvera, P. Nesser, II.

Date: June 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3791

This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an allIPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies.It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.

RFC 3792 Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents

Authors: P. Nesser, II, A. Bergstrom, Ed..

Date: June 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3792

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.

RFC 3793 Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents

Authors: P. Nesser, II, A. Bergstrom, Ed..

Date: June 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3793

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.

RFC 3794 Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents

Authors: P. Nesser, II, A. Bergstrom, Ed..

Date: June 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3794

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an allIPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies.It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.

RFC 3795 Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents

Authors: R. Sofia, P. Nesser, II.

Date: June 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3795

This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6.
To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, andProposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF ApplicationArea documented Standards may experience.

RFC 3796 Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents

Authors: P. Nesser, II, A. Bergstrom, Ed..

Date: June 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3796

This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4Internet to an all IPv6 Internet, many interim steps will be taken.One of these steps is the evolution of current protocols that haveIPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 andIPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented.

RFC 3797 Publicly Verifiable Nominations Committee (NomCom) Random Selection

Authors: D. Eastlake 3rd.

Date: June 2004

Formats: txt html json

Obsoletes: RFC 2777

Status: INFORMATIONAL

DOI: 10.17487/RFC 3797

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases.

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 3801 Voice Profile for Internet Mail - version 2 (VPIMv2)

Authors: G. Vaudreuil, G. Parsons.

Date: June 2004

Formats: txt html json

Obsoletes: RFC 2421, RFC 2423

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3801

This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional InternetEmail-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.
This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in AppendixF. Appendix A summarizes the protocol profiles of this version ofVPIM.

RFC 3802 Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration

Authors: G. Vaudreuil, G. Parsons.

Date: June 2004

Formats: txt json html

Obsoletes: RFC 2422

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3802

This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T inRecommendation G.726.

RFC 3803 Content Duration MIME Header Definition

Authors: G. Vaudreuil, G. Parsons.

Date: June 2004

Formats: txt json html

Obsoletes: RFC 2424

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3803

This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*).

RFC 3804 Voice Profile for Internet Mail (VPIM) Addressing

Authors: G. Parsons.

Date: June 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3804

This document lists the various Voice Profile for Internet Mail(VPIM) email address formats that are currently in common use and defines several new address formats for special case usage.Requirements are imposed on the formats of addresses used in VPIM submission mode.

RFC 3805 Printer MIB v2

Authors: R. Bergman, H. Lewis, I. McDonald.

Date: June 2004

Formats: txt html json

Obsoletes: RFC 1759

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3805

This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759.

RFC 3806 Printer Finishing MIB

Authors: R. Bergman, H. Lewis, I. McDonald.

Date: June 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3806

This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a PrinterSystem.

RFC 3807 V5.2-User Adaptation Layer (V5UA)

Authors: E. Weilandt, N. Khanchandani, S. Rao.

Date: June 2004

Formats: txt json html

Updates: RFC 3057

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3807

This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol(SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface.
This document builds on the ISDN User Adaptation Layer Protocol (RFC3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation.

RFC 3808 IANA Charset MIB

Authors: I. McDonald.

Date: June 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3808

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This IANA Charset MIB is now an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used byIANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset RegistrationProcedures (RFC 2978).

RFC 3809 Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)

Authors: A. Nagarajan, Ed..

Date: June 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3809

This document describes generic requirements for Provider ProvisionedVirtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies.All PPVPN technologies are expected to meet the umbrella set of requirements described in this document.

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 3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)

Authors: C. Srinivasan, A. Viswanathan, T. Nadeau.

Date: June 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3812

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 Multiprotocol LabelSwitching (MPLS) based traffic engineering (TE).

RFC 3813 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)

Authors: C. Srinivasan, A. Viswanathan, T. Nadeau.

Date: June 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3813

This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router(LSR).

RFC 3814 Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)

Authors: T. Nadeau, C. Srinivasan, A. Viswanathan.

Date: June 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3814

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 defining, configuring, and monitoring Forwarding Equivalence Class (FEC) toNext Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS).

RFC 3815 Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)

Authors: J. Cucchiara, H. Sjostrand, J. Luciani.

Date: June 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3815

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 the MultiprotocolLabel Switching, Label Distribution Protocol (LDP).

RFC 3816 Definitions of Managed Objects for RObust Header Compression (ROHC)

Authors: J. Quittek, M. Stiemerling, H. Hartenstein.

Date: June 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3816

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC).The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by allROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-TimeTransport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile.

RFC 3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)

Authors: W. Townsley, R. da Silva.

Date: June 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3817

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet.
L2TP Active Discovery Relay for PPPoE describes a method to relayActive Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs(AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP.

RFC 3818 IANA Considerations for the Point-to-Point Protocol (PPP)

Authors: V. Schryver.

Date: June 2004

Formats: txt html json

Also: BCP 0088

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3818

The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served."

RFC 3819 Advice for Internet Subnetwork Designers

Authors: P. Karn, Ed., C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood.

Date: July 2004

Formats: txt html json

Also: BCP 0089

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3819

This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with theInternet architecture and the implications of their design choices on the performance and efficiency of the Internet.

RFC 3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile

Authors: S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson.

Date: June 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3820

This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term ProxyCertificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system.

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 3823 MIME Media Type for the Systems Biology Markup Language (SBML)

Authors: B. Kovitz.

Date: June 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3823

This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language. SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community.

RFC 3824 Using E.164 numbers with the Session Initiation Protocol (SIP)

Authors: J. Peterson, H. Liu, J. Yu, B. Campbell.

Date: June 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3824

There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations.This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number.

RFC 3825 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information

Authors: J. Polk, J. Schnizlein, M. Linsner.

Date: July 2004

Formats: txt html json

Obsoleted by: RFC 6225

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3825

This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. TheLocation Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included.

RFC 3826 The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model

Authors: U. Blumenthal, F. Maino, K. McCloghrie.

Date: June 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3826

This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model(USM), which is a Security Subsystem for version 3 of the SimpleNetwork Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used inCipher FeedBack Mode (CFB), with a key size of 128 bits.

RFC 3827 Additional Snoop Datalink Types

Authors: K. Sarcar.

Date: June 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3827

The snoop file format provides a way to store and exchange datalink layer packet traces. This document describes extensions to this file format to support new media.

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 3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls

Authors: R. Weltman, M. Smith, M. Wahl.

Date: July 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3829

This document extends the Lightweight Directory Access Protocol(LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation.

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 3831 Transmission of IPv6 Packets over Fibre Channel

Authors: C. DeSanti.

Date: July 2004

Formats: txt html json

Obsoleted by: RFC 4338

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3831

This document specifies the way of encapsulating IPv6 packets overFibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks.

RFC 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 3833 Threat Analysis of the Domain Name System (DNS)

Authors: D. Atkins, R. Austein.

Date: August 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3833

Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats.

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 3835 An Architecture for Open Pluggable Edge Services (OPES)

Authors: A. Barbir, R. Penno, R. Chen, M. Hofmann, H. Orman.

Date: August 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3835

This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service.

RFC 3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols

Authors: A. Beck, M. Hofmann, H. Orman, R. Penno, A. Terzis.

Date: August 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3836

This document specifies the requirements that the OPES (OpenPluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols.

RFC 3837 Security Threats and Risks for Open Pluggable Edge Services (OPES)

Authors: A. Barbir, O. Batuner, B. Srinivas, M. Hofmann, H. Orman.

Date: August 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3837

The document investigates the security threats associated with theOpen Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions.

RFC 3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)

Authors: A. Barbir, O. Batuner, A. Beck, T. Chan, H. Orman.

Date: August 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3838

This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow.

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 3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)

Authors: J. Rosenberg, H. Schulzrinne, P. Kyzivat.

Date: August 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3840

This specification defines mechanisms by which a Session InitiationProtocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field.

RFC 3841 Caller Preferences for the Session Initiation Protocol (SIP)

Authors: J. Rosenberg, H. Schulzrinne, P. Kyzivat.

Date: August 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3841

This document describes a set of extensions to the Session InitiationProtocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences.

RFC 3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)

Authors: R. Mahy.

Date: August 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3842

This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent.

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 3844 IETF Problem Resolution Process

Authors: E. Davies, Ed., J. Hofmann, Ed..

Date: August 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3844

This Informational document records the history of discussions in theProblem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes.
The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG.
While there was working group consensus on the processes for short- term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group.

RFC 3845 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format

Authors: J. Schlyter, Ed..

Date: August 2004

Formats: txt json html

Obsoleted by: RFC 4033, RFC 4034, RFC 4035

Updates: RFC 3755, RFC 2535

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3845

This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space.

RFC 3846 Mobile IPv4 Extension for Carrying Network Access Identifiers

Authors: F. Johansson, T. Johansson.

Date: June 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3846

When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multipleAuthentication Authorization and Accounting (AAA) servers and HomeAgents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of theHome AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes.

RFC 3847 Restart Signaling for Intermediate System to Intermediate System (IS-IS)

Authors: M. Shand, L. Ginsberg.

Date: July 2004

Formats: txt html json

Obsoleted by: RFC 5306

Status: INFORMATIONAL

DOI: 10.17487/RFC 3847

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.
This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts.

RFC 3848 ESMTP and LMTP Transmission Types Registration

Authors: C. Newman.

Date: July 2004

Formats: txt json html

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3848

This registers seven new mail transmission types (ESMTPA, ESMTPS,ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message.

RFC 3849 IPv6 Address Prefix Reserved for Documentation

Authors: G. Huston, A. Lord, P. Smith.

Date: July 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3849

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation.

RFC 3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling

Authors: B. Ramsdell, Ed..

Date: July 2004

Formats: txt json html

Obsoletes: RFC 2632

Obsoleted by: RFC 5750

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3850

This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the InternetX.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280.

RFC 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification

Authors: B. Ramsdell, Ed..

Date: July 2004

Formats: txt json html

Obsoletes: RFC 2633

Obsoleted by: RFC 5751

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3851

This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633.

RFC 3852 Cryptographic Message Syntax (CMS)

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 3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)

Authors: J. Peterson.

Date: July 2004

Formats: txt html json

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3853

RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session InitiationProtocol (SIP). This document updates the normative guidance of RFC3261 to require the Advanced Encryption Standard (AES) for S/MIME.

RFC 3854 Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME)

Authors: P. Hoffman, C. Bonatti, A. Eggen.

Date: July 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3854

This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/MultipurposeInternet Mail Extensions (S/MIME).

RFC 3855 Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400

Authors: P. Hoffman, C. Bonatti.

Date: July 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3855

This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) andSecure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system.

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 3857 A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)

Authors: J. Rosenberg.

Date: August 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3857

This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself.

RFC 3858 An Extensible Markup Language (XML) Based Format for Watcher Information

Authors: J. Rosenberg.

Date: August 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3858

Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes anExtensible Markup Language (XML) document format for such state.

RFC 3859 Common Profile for Presence (CPP)

Authors: J. Peterson.

Date: August 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3859

At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services.

RFC 3860 Common Profile for Instant Messaging (CPIM)

Authors: J. Peterson.

Date: August 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3860

At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services.

RFC 3861 Address Resolution for Instant Messaging and Presence

Authors: J. Peterson.

Date: August 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3861

Presence and instant messaging are defined in RFC 2778. The CommonProfiles for Presence and Instant Messaging define two UniversalResource Identifier (URI) schemes: 'im' for INSTANT INBOXes and'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes.

RFC 3862 Common Presence and Instant Messaging (CPIM): Message Format

Authors: G. Klyne, D. Atkins.

Date: August 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3862

This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for InstantMessaging (CPIM) specification.

RFC 3863 Presence Information Data Format (PIDF)

Authors: H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson.

Date: August 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3863

This memo specifies the Common Profile for Presence (CPP) PresenceInformation Data Format (PIDF) as a common presence data format forCPP-compliant Presence protocols, and also defines a new media type"application/pidf+xml" to represent the XML MIME entity for PIDF.

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 3865 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension

Authors: C. Malamud.

Date: September 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3865

This document proposes an extension to Soliciting Simple MailTransfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing"received" message header are described.

RFC 3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)

Authors: K. Zeilenga, Ed..

Date: July 2004

Formats: txt html json

Obsoletes: RFC 2596

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3866

It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs.This document details the use of Language Tags and Ranges in theLightweight Directory Access Protocol (LDAP).

RFC 3867 Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP)

Authors: Y. Kawatsura, M. Hiroya, H. Beykirch.

Date: November 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3867

The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules.
This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores.
Such interfaces exist at the Consumers', the Merchants' and thePayment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems.

RFC 3868 Signalling Connection Control Part User Adaptation Layer (SUA)

Authors: J. Loughney, Ed., G. Sidebottom, L. Coene, G. Verwimp, J. Keller, B. Bidulock.

Date: October 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3868

This document defines a protocol for the transport of any SignallingConnection Control Part-User signalling over IP using the StreamControl Transmission Protocol. The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture.

RFC 3869 IAB Concerns and Recommendations Regarding Internet Research and Evolution

Authors: R. Atkinson, Ed., S. Floyd, Ed., Internet Architecture Board.

Date: August 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3869

This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research.

RFC 3870 application/rdf+xml Media Type Registration

Authors: A. Swartz.

Date: September 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3870

This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of theResource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide WebConsortium (W3C) design principles of interoperability, evolution, and decentralization.

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 3872 Management Information Base for Telephony Routing over IP (TRIP)

Authors: D. Zinman, D. Walker, J. Jiang.

Date: September 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3872

This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices.

RFC 3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)

Authors: J. Pastor, M. Belinchon.

Date: September 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3873

The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications.
This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP.

RFC 3874 A 224-bit One-way Hash Function: SHA-224

Authors: R. Housley.

Date: September 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3874

This document specifies a 224-bit one-way hash function, calledSHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits.

RFC 3875 The Common Gateway Interface (CGI) Version 1.1

Authors: D. Robinson, K. Coar.

Date: October 2004

Formats: txt json pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3875

The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers.
The interface has been in use by the World-Wide Web (WWW) since 1993.This specification defines the 'current practice' parameters of the'CGI/1.1' interface developed and documented at the U.S. NationalCentre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems.

RFC 3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)

Authors: D. Chadwick, S. Mullan.

Date: September 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3876

This document describes a control for the Lightweight DirectoryAccess Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally.

RFC 3877 Alarm Management Information Base (MIB)

Authors: S. Chisholm, D. Romascanu.

Date: September 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3877

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 management objects used for modelling and storing alarms.

RFC 3878 Alarm Reporting Control Management Information Base (MIB)

Authors: H. Lam, A. Huynh, D. Perkins.

Date: September 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3878

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 controlling the reporting of alarm conditions.

RFC 3879 Deprecating Site Local Addresses

Authors: C. Huitema, B. Carpenter.

Date: September 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3879

This document describes the issues surrounding the use of IPv6 site- local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented.

RFC 3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services

Authors: J. Lennox, X. Wu, H. Schulzrinne.

Date: October 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3880

This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs.

RFC 3881 Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications

Authors: G. Marshall.

Date: September 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3881

This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data.

RFC 3882 Configuring BGP to Block Denial-of-Service Attacks

Authors: D. Turk.

Date: September 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3882

This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis.

RFC 3883 Detecting Inactive Neighbors over OSPF Demand Circuits (DC)

Authors: S. Rao, A. Zinin, A. Roy.

Date: October 2004

Formats: txt html json

Updates: RFC 1793

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3883

OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized inRFC 1793 to minimize the amount of overhead traffic. A part of theOSPF demand circuit extensions is the Hello suppression mechanism.This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "neighbor probing" to address the above problem.

RFC 3884 Use of IPsec Transport Mode for Dynamic Routing

Authors: J. Touch, L. Eggert, Y. Wang.

Date: September 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3884

IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of theVN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database(SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture.IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE).

RFC 3885 SMTP Service Extension for Message Tracking

Authors: E. Allman, T. Hansen.

Date: September 2004

Formats: txt json html

Updates: RFC 3461

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3885

This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking.

RFC 3886 An Extensible Message Format for Message Tracking Responses

Authors: E. Allman.

Date: September 2004

Formats: txt html json

Updates: RFC 3463

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3886

Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message DispositionNotifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.
This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format forDelivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo.

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 3888 Message Tracking Model and Requirements

Authors: T. Hansen.

Date: September 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3888

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 provides a model of message tracking that can be used for understanding theInternet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions.

RFC 3890 A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)

Authors: M. Westerlund.

Date: September 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3890

This document defines a Session Description Protocol (SDP) TransportIndependent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.
The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), theSession Initiation Protocol (SIP), and the Real-Time StreamingProtocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear.

RFC 3891 The Session Initiation Protocol (SIP) "Replaces" Header

Authors: R. Mahy, B. Biggs, R. Dean.

Date: September 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3891

This document defines a new header for use with Session InitiationProtocol (SIP) multi-party applications and call control. TheReplaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "CallPickup". Note that the definition of these example features is non- normative.

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 3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format

Authors: J. Peterson.

Date: September 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3893

RFC 3261 introduces the concept of adding an S/MIME body to a SessionInitiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies(known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given.

RFC 3894 Sieve Extension: Copying Without Side Effects

Authors: J. Degener.

Date: October 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3894

The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox".Actions such as "fileinto" and "redirect" cancel this default behavior.
This document defines a new keyword parameter, ":copy", to be used with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script.

RFC 3895 Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types

Authors: O. Nicklass, Ed..

Date: September 2004

Formats: txt json html

Obsoletes: RFC 2495

Obsoleted by: RFC 4805

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3895

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) InterfaceTypes. This document obsoletes RFC 2495.

RFC 3896 Definitions of Managed Objects for the DS3/E3 Interface Type

Authors: O. Nicklass, Ed..

Date: September 2004

Formats: txt html json

Obsoletes: RFC 2496

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3896

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) InterfaceTypes. This document obsoletes RFC 2496.

RFC 3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication

Authors: A. Barbir.

Date: September 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3897

This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES).

RFC 3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Authors: V. Kalusivalingam.

Date: October 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3898

This document describes four options for Network Information Service(NIS) related configuration information in Dynamic Host ConfigurationProtocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS ClientDomain Name, NIS+ Client Domain name.

RFC 3901 DNS IPv6 Transport Operational Guidelines

Authors: A. Durand, J. Ihren.

Date: September 2004

Formats: txt json html

Also: BCP 0091

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3901

This memo provides guidelines and Best Current Practice for operatingDNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks.

RFC 3902 The "application/soap+xml" media type

Authors: M. Baker, M. Nottingham.

Date: September 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3902

This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0.

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 3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks

Authors: C. Huitema, R. Austein, S. Satapati, R. van der Pol.

Date: September 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3904

This document analyzes issues involved in the transition of"unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed.

RFC 3905 A Template for IETF Patent Disclosures and Licensing Declarations

Authors: V. See, Ed..

Date: September 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3905

This document describes a proposal for one form of a template forIETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668.

RFC 3906 Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels

Authors: N. Shen, H. Smit.

Date: October 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3906

This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by TrafficEngineering.

RFC 3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation

Authors: K. Zeilenga.

Date: October 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3909

This specification describes a Lightweight Directory Access Protocol(LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome.

RFC 3910 The SPIRITS (Services in PSTN requesting Internet Services) Protocol

Authors: V. Gurbani, Ed., A. Brusilovsky, I. Faynberg, J. Gato, H. Lu, M. Unmehopa.

Date: October 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3910

This document describes the Services in PSTN (Public SwitchedTelephone Network) requesting Internet Services (SPIRITS) protocol.The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the IntelligentNetwork (IN) entities. Internet Call Waiting and Internet Caller-IDDelivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built.

RFC 3911 The Session Initiation Protocol (SIP) "Join" Header

Authors: R. Mahy, D. Petrie.

Date: October 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3911

This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call CenterMonitoring". Note that definition of these example features is non- normative.

RFC 3912 WHOIS Protocol Specification

Authors: L. Daigle.

Date: September 2004

Formats: txt html json

Obsoletes: RFC 0954, RFC 0812

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3912

This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954.

RFC 3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification

Authors: D. Thaler.

Date: September 2004

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 3913

This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast"(SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., withUnicast-Prefix-Based Multicast addressing) with different domains.Each of these domains then becomes the root of the shared domain- trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants.

RFC 3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations

Authors: A. Barbir, A. Rousskov.

Date: October 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3914

IETF Internet Architecture Board (IAB) expressed nine architecture- level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations.

RFC 3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)

Authors: S. Hollenbeck.

Date: September 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3915

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by theInternet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing.

RFC 3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)

Authors: X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed..

Date: September 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3916

This document describes base requirements for the Pseudo-WireEmulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, andFrame Relay. Requirements for pseudo-wire emulation of TDM (i.e.,"synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves.

RFC 3917 Requirements for IP Flow Information Export (IPFIX)

Authors: J. Quittek, T. Zseby, B. Claise, S. Zander.

Date: October 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3917

This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes.

RFC 3918 Methodology for IP Multicast Benchmarking

Authors: D. Stopp, B. Hickman.

Date: October 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3918

The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETFBenchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.
The BMWG produces two major classes of documents: BenchmarkingTerminology documents and Benchmarking Methodology documents. TheTerminology documents present the benchmarks and other related terms.The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents.

RFC 3919 Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)

Authors: E. Stephan, J. Palet.

Date: October 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3919

This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base)Version 2 [RFC2021] and the RMON Protocol Identifier Reference[RFC2895].
This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing RMON related IPv6 and MPLS protocol information.

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 3921 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence

Authors: P. Saint-Andre, Ed..

Date: October 2004

Formats: txt json html

Obsoleted by: RFC 6121

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3921

This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779.

RFC 3922 Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)

Authors: P. Saint-Andre.

Date: October 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3922

This memo describes a mapping between the Extensible Messaging andPresence Protocol (XMPP) and the Common Presence and InstantMessaging (CPIM) specifications.

RFC 3923 End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

Authors: P. Saint-Andre.

Date: October 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3923

This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP).

RFC 3924 Cisco Architecture for Lawful Intercept in IP Networks

Authors: F. Baker, B. Foster, C. Sharp.

Date: October 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3924

For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country.

RFC 3925 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)

Authors: J. Littlefield.

Date: October 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3925

The Dynamic Host Configuration Protocol (DHCP) options for VendorClass and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity.

RFC 3926 FLUTE - File Delivery over Unidirectional Transport

Authors: T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh.

Date: October 2004

Formats: txt html json

Obsoleted by: RFC 6726

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3926

This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous LayeredCoding, the base protocol designed for massively scalable multicast distribution.

RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses

Authors: S. Cheshire, B. Aboba, E. Guttman.

Date: May 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3927

To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as aDynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available.It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.
IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.

RFC 3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)

Authors: R. Megginson, Ed., M. Smith, O. Natkovich, J. Parham.

Date: October 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3928

This document defines the Lightweight Directory Access Protocol(LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content.

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 3930 The Protocol versus Document Points of View in Computer Protocols

Authors: D. Eastlake 3rd.

Date: October 2004

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3930

This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced.

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 3932 The IESG and RFC Editor Documents: Procedures

Authors: H. Alvestrand.

Date: October 2004

Formats: txt html json

Obsoleted by: RFC 5742

Updates: RFC 2026, RFC 3710

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3932

This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.
This document updates procedures described in RFC 2026 and RFC 3710.

RFC 3933 A Model for IETF Process Experiments

Authors: J. Klensin, S. Dawkins.

Date: November 2004

Formats: txt html json

Also: BCP 0093

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3933

The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification.The first mechanism has often proven to be too lightweight, the second too heavyweight.
This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted.

RFC 3934 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists

Authors: M. Wasserman.

Date: October 2004

Formats: txt json html

Updates: RFC 2418

Also: BCP 0025

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3934

This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals.

RFC 3935 A Mission Statement for the IETF

Authors: H. Alvestrand.

Date: October 2004

Formats: txt json html

Also: BCP 0095

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3935

This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point.

RFC 3936 Procedures for Modifying the Resource reSerVation Protocol (RSVP)

Authors: K. Kompella, J. Lang.

Date: October 2004

Formats: txt html json

Updates: RFC 3209, RFC 2205

Also: BCP 0096

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3936

This memo specifies procedures for modifying the Resource reSerVationProtocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects.

RFC 3937 A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC)

Authors: M. Steidl.

Date: October 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3937

This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International PressTelecommunications Council (IPTC). These resources include XML DataType Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others.

RFC 3938 Video-Message Message-Context

Authors: T. Hansen.

Date: October 2004

Formats: txt json html

Updates: RFC 3458

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3938

The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message".
A receiving user agent (UA) may use this information as a hint to optimally present the message.

RFC 3939 Calling Line Identification for Voice Mail Messages

Authors: G. Parsons, J. Maruszak.

Date: December 2004

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3939

This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID andCalled_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message.Caller-name provides the name of the person sending the message.

RFC 3940 Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol

Authors: B. Adamson, C. Bormann, M. Handley, J. Macker.

Date: November 2004

Formats: txt html json

Obsoleted by: RFC 5740

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3940

This document describes the messages and procedures of the Negative- acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such asTransmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways.The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design.

RFC 3941 Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks

Authors: B. Adamson, C. Bormann, M. Handley, J. Macker.

Date: November 2004

Formats: txt html json

Obsoleted by: RFC 5401

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3941

This document discusses the creation of negative-acknowledgment(NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols.

RFC 3942 Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options

Authors: B. Volz.

Date: November 2004

Formats: txt json html

Updates: RFC 2132

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3942

This document updates RFC 2132 to reclassify Dynamic HostConfiguration Protocol version 4 (DHCPv4) option codes 128 to 223(decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options.

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 3944 H.350 Directory Services

Authors: T. Johnson, S. Okubo, S. Campos.

Date: December 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3944

The International Telecommunications Union Standardization Sector(ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store.
Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T RecommendationsH.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version.

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 3946 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control

Authors: E. Mannie, D. Papadimitriou.

Date: October 2004

Formats: txt json html

Obsoleted by: RFC 4606

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3946

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

RFC 3947 Negotiation of NAT-Traversal in the IKE

Authors: T. Kivinen, B. Swander, A. Huttunen, V. Volpe.

Date: January 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3947

This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes inInternet Key Exchange (IKE).

RFC 3948 UDP Encapsulation of IPsec ESP Packets

Authors: A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. Stenberg.

Date: January 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3948

This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets insideUDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used withInternet Key Exchange (IKE).

RFC 3949 File Format for Internet Fax

Authors: R. Buckley, D. Venable, L. McIntyre, G. Parsons, J. Rafferty.

Date: February 2005

Formats: txt html json

Obsoletes: RFC 2301

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3949

This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing.
This RFC 2301 revision describes the Tag Image File Format (TIFF) representation of image data specified by the InternationalTelecommunication Union (ITU-T) Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF for Fax eXtended (TIFF-FX). It formally defines minimal, extended, and lossless Joint Bi-level Image experts Group(JBIG) profiles (Profiles S, F, J) for black-and-white fax and baseJPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C,L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations.

RFC 3950 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration

Authors: L. McIntyre, G. Parsons, J. Rafferty.

Date: February 2005

Formats: txt html json

Obsoletes: RFC 3250

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3950

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for InternetFax and its extensions.

RFC 3951 Internet Low Bit Rate Codec (iLBC)

Authors: S. Andersen, A. Duric, H. Astrom, R. Hagen, W. Kleijn, J. Linden.

Date: December 2004

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3951

This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound(GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets.

RFC 3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech

Authors: A. Duric, S. Andersen.

Date: December 2004

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3952

This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME andSession Description Protocol (SDP).

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 3954 Cisco Systems NetFlow Services Export Version 9

Authors: B. Claise, Ed..

Date: October 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3954

This document specifies the data export format for version 9 of CiscoSystems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics.

RFC 3955 Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)

Authors: S. Leinen.

Date: October 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3955

This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification.

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 3957 Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4

Authors: C. Perkins, P. Calhoun.

Date: March 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3957

Authentication, Authorization, and Accounting (AAA) servers, such asRADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers.Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA SecurityAssociation with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility SecurityAssociations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to createMobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent.

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 3959 The Early Session Disposition Type for the Session Initiation Protocol (SIP)

Authors: G. Camarillo.

Date: December 2004

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3959

This document defines a new disposition type (early-session) for theContent-Disposition header field in the Session Initiation Protocol(SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs.

RFC 3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)

Authors: G. Camarillo, H. Schulzrinne.

Date: December 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3960

This document describes how to manage early media in the SessionInitiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation.

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 3963 Network Mobility (NEMO) Basic Support Protocol

Authors: V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert.

Date: January 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3963

This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network.

RFC 3964 Security Considerations for 6to4

Authors: P. Savola, C. Patel.

Date: December 2004

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3964

The IPv6 interim mechanism 6to4 (RFC3056) uses automaticIPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems.

RFC 3965 A Simple Mode of Facsimile Using Internet Mail

Authors: K. Toyoda, H. Ohno, J. Murai, D. Wing.

Date: December 2004

Formats: txt html json

Obsoletes: RFC 2305

Status: DRAFT STANDARD

DOI: 10.17487/RFC 3965

This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow.The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet MailExtensions (MIME), and Tagged Image File Format (TIFF) for Facsimile.It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them.
This document is a revision of RFC 2305. There have been no technical changes.

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 3968 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)

Authors: G. Camarillo.

Date: December 2004

Formats: txt html json

Updates: RFC 3427

Also: BCP 0098

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 3968

This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry.

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 3974 SMTP Operational Experience in Mixed IPv4/v6 Environments

Authors: M. Nakamura, J. Hagino.

Date: January 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3974

This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.
This document does not define any new protocol.

RFC 3975 OMA-IETF Standardization Collaboration

Authors: G. Huston, Ed., I. Leuca, Ed..

Date: January 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3975

This document describes the standardization collaboration between theOpen Mobile Alliance (OMA) and the Internet Engineering Task Force(IETF).

RFC 3976 Interworking SIP and Intelligent Network (IN) Applications

Authors: V. K. Gurbani, F. Haerens, V. Rastogi.

Date: January 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3976

Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from SessionInitiation Protocol (SIP) endpoints for an IP-host-to-phone call.The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in thePSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP).

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 3980 T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names

Authors: M. Krueger, M. Chadalapaka, R. Elliott.

Date: February 2005

Formats: txt html json

Obsoleted by: RFC 7143

Updates: RFC 3720

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3980

Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the "Network Address Authority" (NAA) worldwide naming format defined by the InterNational Committee for Information TechnologyStandards (INCITS) T11 - Fibre Channel (FC) protocols and used bySerial Attached SCSI (SAS). This document updates RFC 3720.

RFC 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 3982 IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)

Authors: A. Newton, M. Sanz.

Date: January 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3982

This document describes an Internet Registry Information Service(IRIS) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars.

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 3984 RTP Payload Format for H.264 Video

Authors: S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer.

Date: February 2005

Formats: txt html json

Obsoleted by: RFC 6184

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3984

This memo describes an RTP Payload format for the ITU-TRecommendation H.264 video codec and the technically identicalISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network AbstractionLayer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, toInternet video streaming with interleaved transmission, to high bit- rate video-on-demand.

RFC 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 3987 Internationalized Resource Identifiers (IRIs)

Authors: M. Duerst, M. Suignard.

Date: January 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3987

This document defines a new protocol element, the InternationalizedResource Identifier (IRI), as a complement to the Uniform ResourceIdentifier (URI). An IRI is a sequence of characters from theUniversal Character Set (Unicode/ISO 10646). A mapping from IRIs toURIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.
The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.

RFC 3988 Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol

Authors: B. Black, K. Kompella.

Date: January 2005

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 3988

Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the LabelDistribution Protocol (LDP) does not have the ability to signal theMTU for a Label Switched Path (LSP) to the ingress Label SwitchingRouter (LSR). In the absence of this functionality, the MTU for eachLSP must be statically configured by network operators or by equivalent off-line mechanisms.
This document specifies experimental extensions to LDP in support ofLSP MTU discovery.

RFC 3989 Middlebox Communications (MIDCOM) Protocol Semantics

Authors: M. Stiemerling, J. Quittek, T. Taylor.

Date: February 2005

Formats: txt html json

Obsoleted by: RFC 5189

Status: INFORMATIONAL

DOI: 10.17487/RFC 3989

This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from theMIDCOM requirements, from the MIDCOM framework, and from working group decisions.

RFC 3990 Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement

Authors: B. O'Hara, P. Calhoun, J. Kempf.

Date: February 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3990

This document describes the Configuration and Provisioning forWireless Access Points (CAPWAP) problem statement.

RFC 3991 Media Gateway Control Protocol (MGCP) Redirect and Reset Package

Authors: B. Foster, F. Andreasen.

Date: February 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 3991

The base Media Gateway Control Protocol (MGCP) specification (RFC3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order.

RFC 3992 Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism

Authors: B. Foster, F. Andreasen.

Date: February 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3992

A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures.

RFC 3993 Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option

Authors: R. Johnson, T. Palaniappan, M. Stapp.

Date: March 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3993

This memo defines a new Subscriber-ID suboption for the Dynamic HostConfiguration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable"Subscriber-ID" with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure.

RFC 3994 Indication of Message Composition for Instant Messaging

Authors: H. Schulzrinne.

Date: January 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3994

In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves.

RFC 3995 Internet Printing Protocol (IPP): Event Notifications and Subscriptions

Authors: R. Herriot, T. Hastings.

Date: March 2005

Formats: txt html json

Updates: RFC 2911, RFC 2910

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3995

This document describes an OPTIONAL extension to the InternetPrinting Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910).This extension allows a client to subscribe to printing relatedEvents. Subscriptions are modeled as Subscription Objects. TheSubscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or PullDelivery Method (i.e., protocol).
A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting aJob with subscription information. A client associates SubscriptionObjects with the Printer by performing a Create-Printer-Subscriptions operation. Four other operations are defined for SubscriptionObjects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription.

RFC 3996 Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications

Authors: R. Herriot, T. Hastings, H. Lewis.

Date: March 2005

Formats: txt json html

Updates: RFC 2911

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3996

This document describes an extension to the Internet PrintingProtocol1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the"Internet Printing Protocol (IPP): Event Notifications andSubscriptions" specification (RFC 3995). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995. TheNotification Recipient, acting as a client, fetches (pulls) EventNotifications by using the Get-Notifications operation defined in this document.

RFC 3997 Internet Printing Protocol (IPP): Requirements for IPP Notifications

Authors: T. Hastings, Ed., R. K. deBry, H. Lewis.

Date: March 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 3997

This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPPService.

RFC 3998 Internet Printing Protocol (IPP): Job and Printer Administrative Operations

Authors: C. Kugler, H. Lewis, T. Hastings, Ed..

Date: March 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 3998

This document specifies the following 16 additional OPTIONAL system administration operations for use with the Internet PrintingProtocol/1.1 (IPP), plus a few associated attributes, values, and status codes, and using the IPP Printer object to manage printer fan-out and fan-in.
Printer operations: Job operations:Enable-Printer and Disable-Printer Reprocess-JobPause-Printer-After-Current-Job Cancel-Current-JobHold-New-Jobs and Release-Held-New-Jobs Suspend-Current-JobDeactivate-Printer and Activate-Printer Resume-JobRestart-Printer Promote-JobShutdown-Printer and Startup-Printer Schedule-Job-After

RFC 4001 Textual Conventions for Internet Network Addresses

Authors: M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder.

Date: February 2005

Formats: txt html json

Obsoletes: RFC 3291

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4001

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations.

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 4003 GMPLS Signaling Procedure for Egress Control

Authors: L. Berger.

Date: February 2005

Formats: txt json html

Updates: RFC 3473

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4003

This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a LabelSwitched Path (LSP). This control is also known as "Egress Control".Support for Egress Control is implicit in Generalized Multi-ProtocolLabel Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures.

RFC 4004 Diameter Mobile IPv4 Application

Authors: P. Calhoun, T. Johansson, C. Perkins, T. Hiller, Ed., P. McCann.

Date: August 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4004

This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers.

RFC 4005 Diameter Network Access Server Application

Authors: P. Calhoun, G. Zorn, D. Spence, D. Mitton.

Date: August 2005

Formats: txt html json

Obsoleted by: RFC 7155

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4005

This document describes the Diameter protocol application used forAuthentication, Authorization, and Accounting (AAA) services in theNetwork Access Server (NAS) environment. When combined with theDiameter Base protocol, Transport Profile, and ExtensibleAuthentication Protocol specifications, this application specification satisfies typical network access services requirements.
Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS andDiameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations.
The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol.

RFC 4006 Diameter Credit-Control Application

Authors: H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney.

Date: August 2005

Formats: txt json html

Obsoleted by: RFC 8506

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4006

This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services.

RFC 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 4008 Definitions of Managed Objects for Network Address Translators (NAT)

Authors: R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, C. Wang.

Date: March 2005

Formats: txt html json

Obsoleted by: RFC 7658

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4008

This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function.This MIB module may be used for configuration as well as monitoring of a device capable of NAT function.

RFC 4009 The SEED Encryption Algorithm

Authors: J. Park, S. Lee, J. Kim, J. Lee.

Date: February 2005

Formats: txt html json

Obsoleted by: RFC 4269

Status: INFORMATIONAL

DOI: 10.17487/RFC 4009

This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).

RFC 4010 Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)

Authors: J. Park, S. Lee, J. Kim, J. Lee.

Date: February 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4010

This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).
SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs).One OID class defines the content encryption algorithms and the other defines the key encryption algorithms.

RFC 4011 Policy Based Management MIB

Authors: S. Waldbusser, J. Saperia, T. Hongal.

Date: March 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4011

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol(SNMP) infrastructures, a scripting language, and a script execution environment.

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 4013 SASLprep: Stringprep Profile for User Names and Passwords

Authors: K. Zeilenga.

Date: February 2005

Formats: txt json html

Obsoleted by: RFC 7613

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4013

This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the"SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used bySimple Authentication and Security Layer (SASL) mechanisms (such asPLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords.

RFC 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 4015 The Eifel Response Algorithm for TCP

Authors: R. Ludwig, A. Gurtov.

Date: February 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4015

Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided.

RFC 4016 Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements

Authors: M. Parthasarathy.

Date: March 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4016

This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol.

RFC 4017 Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs

Authors: D. Stanley, J. Walker, B. Aboba.

Date: March 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4017

The IEEE 802.11i MAC Security Enhancements Amendment makes use ofIEEE 802.1X, which in turn relies on the Extensible AuthenticationProtocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes.

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 4020 Early IANA Allocation of Standards Track Code Points

Authors: K. Kompella, A. Zinin.

Date: February 2005

Formats: txt html json

Obsoleted by: RFC 7120

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4020

This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication.

RFC 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 4022 Management Information Base for the Transmission Control Protocol (TCP)

Authors: R. Raghunarayan, Ed..

Date: March 2005

Formats: txt json html

Obsoletes: RFC 2452, RFC 2012

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4022

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 implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012.

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 4024 Voice Messaging Client Behaviour

Authors: G. Parsons, J. Maruszak.

Date: July 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4024

This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message.

RFC 4025 A Method for Storing IPsec Keying Material in DNS

Authors: M. Richardson.

Date: March 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4025

This document describes a new resource record for the Domain NameSystem (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question.
This record replaces the functionality of the sub-type #4 of the KEYResource Record, which has been obsoleted by RFC 3445.

RFC 4026 Provider Provisioned Virtual Private Network (VPN) Terminology

Authors: L. Andersson, T. Madsen.

Date: March 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4026

The widespread interest in provider-provisioned Virtual PrivateNetwork (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first ProviderProvisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services.
To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive.

RFC 4027 Domain Name System Media Types

Authors: S. Josefsson.

Date: April 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4027

This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035.

RFC 4028 Session Timers in the Session Initiation Protocol (SIP)

Authors: S. Donovan, J. Rosenberg.

Date: April 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4028

This document defines an extension to the Session Initiation Protocol(SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields:Session-Expires, which conveys the lifetime of the session, andMin-SE, which conveys the minimum allowed value for the session timer.

RFC 4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks

Authors: M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola.

Date: March 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4029

This document describes different scenarios for the introduction ofIPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated.Known challenges are also identified.

RFC 4030 The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option

Authors: M. Stapp, T. Lemon.

Date: March 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4030

The Dynamic Host Configuration Protocol (DHCP) Relay AgentInformation Option (RFC 3046) conveys information between a DHCPRelay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages.

RFC 4031 Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)

Authors: M. Carugi, Ed., D. McDysan, Ed..

Date: April 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4031

This document provides requirements for Layer 3 Virtual PrivateNetworks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP- based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider.

RFC 4032 Update to the Session Initiation Protocol (SIP) Preconditions Framework

Authors: G. Camarillo, P. Kyzivat.

Date: March 2005

Formats: txt json html

Updates: RFC 3312

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4032

This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility.

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 4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core

Authors: A. Rousskov.

Date: March 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4037

This document specifies the core of the Open Pluggable Edge Services(OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCPCore consists of application-agnostic mechanisms essential for efficient support of typical adaptations.

RFC 4038 Application Aspects of IPv6 Transition

Authors: M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro.

Date: March 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4038

As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to developIP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period.

RFC 4039 Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)

Authors: S. Park, P. Kim, B. Volz.

Date: March 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4039

This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a2-message exchange rather than the usual 4-message exchange, expediting client configuration.

RFC 4040 RTP Payload Format for a 64 kbit/s Transparent Call

Authors: R. Kreuter.

Date: April 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4040

This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called"Clearmode". It also serves as registration for a related MIME type called "audio/clearmode".
"Clearmode" is a basic feature of VoIP Media Gateways.

RFC 4041 Requirements for Morality Sections in Routing Area Drafts

Authors: A. Farrel.

Date: 1 April 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4041

It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal.
This document specifies a requirement for all new Routing AreaInternet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain.

RFC 4042 UTF-9 and UTF-18 Efficient Transformation Formats of Unicode

Authors: M. Crispin.

Date: 1 April 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4042

ISO-10646 defines a large character set called the UniversalCharacter Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions toISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization.
The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet.
This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient.

RFC 4043 Internet X.509 Public Key Infrastructure Permanent Identifier

Authors: D. Pinkas, T. Gindin.

Date: May 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4043

This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used by aCA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed.
The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA.

RFC 4044 Fibre Channel Management MIB

Authors: K. McCloghrie.

Date: May 2005

Formats: txt json html

Obsoletes: RFC 2837

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4044

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 information related to the Fibre Channel.

RFC 4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)

Authors: G. Bourdon.

Date: April 2005

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4045

The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels.

RFC 4046 Multicast Security (MSEC) Group Key Management Architecture

Authors: M. Baugher, R. Canetti, L. Dondeti, F. Lindholm.

Date: April 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4046

This document defines the common architecture for Multicast Security(MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication.

RFC 4047 MIME Sub-type Registrations for Flexible Image Transport System (FITS)

Authors: S. Allen, D. Wells.

Date: April 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4047

This document describes the registration of the Multipurpose InternetMail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible ImageTransport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS.

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 4049 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1

Authors: R. Housley.

Date: April 2005

Formats: txt json html

Obsoleted by: RFC 6019

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4049

This document specifies a new ASN.1 type for representing time:BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary- signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852.

RFC 4050 Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures

Authors: S. Blake-Wilson, G. Karlinger, T. Kobayashi, Y. Wang.

Date: April 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4050

This document specifies how to use Elliptic Curve Digital SignatureAlgorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference.

RFC 4051 Additional XML Security Uniform Resource Identifiers (URIs)

Authors: D. Eastlake 3rd.

Date: April 2005

Formats: txt json html

Obsoleted by: RFC 6931

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4051

A number of Uniform Resource Identifiers (URIs) intended for use withXML Digital Signatures, Encryption, and Canonicalization are defined.These URIs identify algorithms and types of keying information.

RFC 4052 IAB Processes for Management of IETF Liaison Relationships

Authors: L. Daigle, Ed., Internet Architecture Board.

Date: April 2005

Formats: txt html json

Also: BCP 0102

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4052

This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and otherStandards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established.

RFC 4053 Procedures for Handling Liaison Statements to and from the IETF

Authors: S. Trowbridge, S. Bradner, F. Baker.

Date: April 2005

Formats: txt html json

Also: BCP 0103

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4053

This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations(SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community.
The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. TheIETF is only obligated to respond if there is an agreed liaison relationship, however.

RFC 4054 Impairments and Other Constraints on Optical Layer Routing

Authors: J. Strand, Ed., A. Chiu, Ed..

Date: May 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4054

Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS). Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1)Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints.

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 4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)

Authors: J. Schaad.

Date: June 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4056

This document specifies the conventions for using the RSASSA-PSS (RSAProbabilistic Signature Scheme) digital signature algorithm with theCryptographic Message Syntax (CMS).

RFC 4057 IPv6 Enterprise Network Scenarios

Authors: J. Bound, Ed..

Date: June 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4057

This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios.Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment.The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document.

RFC 4058 Protocol for Carrying Authentication for Network Access (PANA) Requirements

Authors: A. Yegin, Ed., Y. Ohba, R. Penno, G. Tsirtsis, C. Wang.

Date: May 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4058

It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of theAAA infrastructure.

RFC 4059 Internet X.509 Public Key Infrastructure Warranty Certificate Extension

Authors: D. Linsenbardt, S. Pontius, A. Sturgeon.

Date: May 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4059

This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension.

RFC 4060 RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding

Authors: Q. Xie, D. Pearce.

Date: May 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4060

This document specifies RTP payload formats for encapsulatingEuropean Telecommunications Standards Institute (ETSI) EuropeanStandard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSRExtended Front-end (XFE), and ES 202 212 DSR Extended AdvancedFront-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems.

RFC 4061 Benchmarking Basic OSPF Single Router Control Plane Convergence

Authors: V. Manral, R. White, A. Shaikh.

Date: April 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4061

This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance.
NOTE: In this document, the word "convergence" relates to single router control plane convergence only.

RFC 4062 OSPF Benchmarking Terminology and Concepts

Authors: V. Manral, R. White, A. Shaikh.

Date: April 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4062

This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere(and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol.

RFC 4063 Considerations When Using Basic OSPF Convergence Benchmarks

Authors: V. Manral, R. White, A. Shaikh.

Date: April 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4063

This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested.

RFC 4064 Experimental Message, Extensions, and Error Codes for Mobile IPv4

Authors: A. Patel, K. Leung.

Date: May 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4064

Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements toMobile IPv4 messages before a formal standards proposal is issued.

RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations

Authors: J. Kempf.

Date: July 2005

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4065

The Seamoby Candidate Access Router Discovery (CARD) protocol and theContext Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, StreamControl Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options.This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols.

RFC 4066 Candidate Access Router Discovery (CARD)

Authors: M. Liebsch, Ed., A. Singh, Ed., H. Chaskar, D. Funato, E. Shim.

Date: July 2005

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4066

To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery ofCARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD.

RFC 4067 Context Transfer Protocol (CXTP)

Authors: J. Loughney, Ed., M. Nakhjiri, C. Perkins, R. Koodli.

Date: July 2005

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4067

This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node.

RFC 4068 Fast Handovers for Mobile IPv6

Authors: R. Koodli, Ed..

Date: July 2005

Formats: txt json html

Obsoleted by: RFC 5268

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4068

Mobile IPv6 enables a Mobile Node to maintain its connectivity to theInternet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and BindingUpdate, is often unacceptable to real-time traffic such as Voice overIP. Reducing the handover latency could be beneficial to non-real- time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency.

RFC 4069 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding

Authors: M. Dodge, B. Ray.

Date: May 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4069

This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed DigitalSubscriber Line (VDSL) interfaces using Single Carrier Modulation(SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB,RFC 3728, which handles line code independent objects.

RFC 4070 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding

Authors: M. Dodge, B. Ray.

Date: May 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4070

This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed DigitalSubscriber Line (VDSL) interfaces using Multiple Carrier Modulation(MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB,RFC 3728, which handles line code independent objects.

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 4073 Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)

Authors: R. Housley.

Date: May 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4073

This document describes a convention for using the CryptographicMessage Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content.

RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses

Authors: Y. Morishita, T. Jinmei.

Date: May 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4074

There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can blockIPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects.

RFC 4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6

Authors: V. Kalusivalingam.

Date: May 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4075

This document describes a new DHCPv6 option for passing a list ofSimple Network Time Protocol (SNTP) server addresses to a client.

RFC 4076 Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Authors: T. Chown, S. Venaas, A. Vijayabhaskar.

Date: May 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4076

IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and statelessDHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document.

RFC 4077 A Negative Acknowledgement Mechanism for Signaling Compression

Authors: A.B. Roach.

Date: May 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4077

This document describes a mechanism that allows Signaling Compression(SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations.

RFC 4078 The TV-Anytime Content Reference Identifier (CRID)

Authors: N. Earnshaw, S. Aoki, A. Ashley, W. Kameyama.

Date: May 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4078

The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet.
The initial intended application is as an embedded link within scheduled programme description metadata that can be used by the home user or agent to associate a programme selection with the corresponding programme location information for subsequent automatic acquisition.
This document reproduces the TV-Anytime CRID definition found in theTV-Anytime content referencing specification, and is published as anRFC for ease of access and registration with the Internet AssignedNumbers Authority (IANA).

RFC 4079 A Presence Architecture for the Distribution of GEOPRIV Location Objects

Authors: J. Peterson.

Date: July 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4079

GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation ofGEOPRIV.

RFC 4080 Next Steps in Signaling (NSIS): Framework

Authors: R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch.

Date: June 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4080

The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.
This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application.

RFC 4081 Security Threats for Next Steps in Signaling (NSIS)

Authors: H. Tschofenig, D. Kroeselberg.

Date: June 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4081

This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite.

RFC 4082 Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction

Authors: A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe.

Date: June 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4082

This document introduces Timed Efficient Stream Loss-tolerantAuthentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.
This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts.

RFC 4083 Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)

Authors: M. Garcia-Martin.

Date: May 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4083

The 3rd-Generation Partnership Project (3GPP) has selected SessionInitiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part ofRelease 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP forRelease 5 of the 3GPP IMS in cellular networks.

RFC 4084 Terminology for Describing Internet Connectivity

Authors: J. Klensin.

Date: May 2005

Formats: txt json html

Also: BCP 0104

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4084

As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered.

RFC 4085 Embedding Globally-Routable Internet Addresses Considered Harmful

Authors: D. Plonka.

Date: June 2005

Formats: txt json html

Also: BCP 0105

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4085

This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives.This document is intended to clarify best current practices in this regard.

RFC 4086 Randomness Requirements for Security

Authors: D. Eastlake 3rd, J. Schiller, S. Crocker.

Date: June 2005

Formats: txt html json

Obsoletes: RFC 1750

Also: BCP 0106

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4086

Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo- security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.
Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose.It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications.

RFC 4087 IP Tunnel MIB

Authors: D. Thaler.

Date: June 2005

Formats: txt html json

Obsoletes: RFC 2667

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4087

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extensionMIB modules may be designed for managing security-specific objects.This MIB module does not support tunnels over non-IP networks.Management of such tunnels may be supported by other MIB modules.This memo obsoletes RFC 2667.

RFC 4088 Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)

Authors: D. Black, K. McCloghrie, J. Schoenwaelder.

Date: June 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4088

The Simple Network Management Protocol (SNMP) and the InternetStandard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access(including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform ResourceIdentifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.
This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances.

RFC 4089 IAB and IESG Recommendation for IETF Administrative Restructuring

Authors: S. Hollenbeck, Ed., IAB and IESG.

Date: May 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4089

This document describes a joint recommendation of the InternetArchitecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force.The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record.

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 4091 The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework

Authors: G. Camarillo, J. Rosenberg.

Date: June 2005

Formats: txt json html

Obsoleted by: RFC 5245

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4091

This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream.

RFC 4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)

Authors: G. Camarillo, J. Rosenberg.

Date: June 2005

Formats: txt html json

Obsoleted by: RFC 5245

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4092

This document describes how to use the Alternative Network AddressTypes (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT.

RFC 4093 Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways

Authors: F. Adrangi, Ed., H. Levkowetz, Ed..

Date: August 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4093

Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions.

RFC 4094 Analysis of Existing Quality-of-Service Signaling Protocols

Authors: J. Manner, X. Fu.

Date: May 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4094

This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area.

RFC 4095 Attaching Meaning to Solicitation Class Keywords

Authors: C. Malamud.

Date: May 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4095

This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the NoSoliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new "No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.
This document specifies an application based on the DynamicDelegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the"org.example.adv" solicitation class keyword.

RFC 4096 Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best

Authors: C. Malamud.

Date: May 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4096

This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective.

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 4098 Terminology for Benchmarking BGP Device Convergence in the Control Plane

Authors: H. Berkowitz, E. Davies, Ed., S. Hares, P. Krishnaswamy, M. Lepp.

Date: June 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4098

This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant.

RFC 4101 Writing Protocol Models

Authors: E. Rescorla, IAB.

Date: June 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4101

The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system.

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 4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)

Authors: M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner.

Date: June 2005

Formats: txt json html

Updates: RFC 3703

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4104

This document defines a number of changes and extensions to thePolicy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC3703) based on the model extensions defined by the Policy CoreInformation Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types.Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703.

RFC 4105 Requirements for Inter-Area MPLS Traffic Engineering

Authors: J.-L. Le Roux, Ed., J.-P. Vasseur, Ed., J. Boyle, Ed..

Date: June 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4105

This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE).It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements.

RFC 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)

Authors: J. Viega, D. McGrew.

Date: June 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4106

This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating SecurityPayload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations.

RFC 4107 Guidelines for Cryptographic Key Management

Authors: S. Bellovin, R. Housley.

Date: June 2005

Formats: txt html json

Also: BCP 0107

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4107

The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions.When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer.

RFC 4108 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages

Authors: R. Housley.

Date: August 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4108

This document describes the use of the Cryptographic Message Syntax(CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication.Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package.

RFC 4109 Algorithms for Internet Key Exchange version 1 (IKEv1)

Authors: P. Hoffman.

Date: May 2005

Formats: txt json html

Updates: RFC 2409

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4109

The required and suggested algorithms in the original Internet KeyExchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today.

RFC 4110 A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)

Authors: R. Callon, M. Suzuki.

Date: July 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4110

This document provides a framework for Layer 3 Provider-ProvisionedVirtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document.

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 4112 Electronic Commerce Modeling Language (ECML) Version 2 Specification

Authors: D. Eastlake 3rd.

Date: June 2005

Formats: txt html json

Updates: RFC 3106

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4112

Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated. This is the second version of an Electronic CommerceModeling Language (ECML) and is intended to meet the requirements ofRFC 3505.

RFC 4113 Management Information Base for the User Datagram Protocol (UDP)

Authors: B. Fenner, J. Flick.

Date: June 2005

Formats: txt html json

Obsoletes: RFC 2454, RFC 2013

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4113

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 implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454.

RFC 4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)

Authors: S. Hollenbeck.

Date: June 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4114

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers.

RFC 4115 A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic

Authors: O. Aboul-Magd, S. Rabie.

Date: July 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4115

This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic.Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices.

RFC 4116 IPv4 Multihoming Practices and Limitations

Authors: J. Abley, K. Lindqvist, E. Davies, B. Black, V. Gill.

Date: July 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4116

Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6).

RFC 4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)

Authors: G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk.

Date: June 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4117

This document describes how to invoke transcoding services usingSession Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals.

RFC 4118 Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)

Authors: L. Yang, P. Zerfos, E. Sadot.

Date: June 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4118

This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzingWireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities.

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 4122 A Universally Unique IDentifier (UUID) URN Namespace

Authors: P. Leach, M. Mealling, R. Salz.

Date: July 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4122

This specification defines a Uniform Resource Name namespace forUUIDs (Universally Unique IDentifier), also known as GUIDs (GloballyUnique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in theApollo Network Computing System and later in the Open SoftwareFoundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.
This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group).Information from earlier versions of the DCE specification have been incorporated into this document.

RFC 4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements

Authors: H. Schulzrinne, C. Agboh.

Date: July 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4123

This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function(SIP-H.323 IWF) that will allow the interworking between SIP andH.323.

RFC 4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering

Authors: F. Le Faucheur, Ed..

Date: June 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4124

This document specifies the protocol extensions for support ofDiffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior GatewayProtocol (IGP) extensions already defined for existing MPLS TrafficEngineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS TrafficEngineering. These extensions address the requirements for DS-TE spelled out in RFC 3564.

RFC 4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering

Authors: F. Le Faucheur, W. Lai.

Date: June 2005

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4125

This document provides specifications for one Bandwidth ConstraintsModel for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model.

RFC 4126 Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons

Authors: J. Ash.

Date: June 2005

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4126

This document complements the Diffserv-aware MPLS Traffic Engineering(DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) BandwidthConstraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting aBandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks.

RFC 4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering

Authors: F. Le Faucheur, Ed..

Date: June 2005

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4127

This document provides specifications for one Bandwidth ConstraintsModel for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model.

RFC 4128 Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation

Authors: W. Lai.

Date: June 2005

Formats: txt pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4128

"Differentiated Services (Diffserv)-aware MPLS Traffic EngineeringRequirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, theMaximum Allocation and the Russian Dolls, are described therein.This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing.

RFC 4129 Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol

Authors: R. Mukundan, K. Morneault, N. Mangalpally.

Date: September 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4129

This document defines a mechanism for backhauling Digital PrivateNetwork Signaling System 1 (DPNSS 1) and Digital Access SignalingSystem 2 (DASS 2) messages over IP by extending the ISDN UserAdaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, specified in ND1301:2001/03 (formerly BTNR 188), is used to interconnect Private Branch Exchanges (PBX) in a private network.DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN.This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation.

RFC 4130 MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)

Authors: D. Moberg, R. Drummond.

Date: July 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4130

This document provides an applicability statement (RFC 2026, Section3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the AmericanNational Standards Committee (ANSI) X12 format or the UN ElectronicData Interchange for Administration, Commerce, and Transport(UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335.

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 4132 Addition of Camellia Cipher Suites to Transport Layer Security (TLS)

Authors: S. Moriai, A. Kato, M. Kanda.

Date: July 2005

Formats: txt html json

Obsoleted by: RFC 5932

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4132

This document proposes the addition of new cipher suites to theTransport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm.

RFC 4133 Entity MIB (Version 3)

Authors: A. Bierman, K. McCloghrie.

Date: August 2005

Formats: txt html json

Obsoletes: RFC 2737

Obsoleted by: RFC 6933

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4133

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737).

RFC 4134 Examples of S/MIME Messages

Authors: P. Hoffman, Ed..

Date: July 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4134

This document gives examples of message bodies formatted usingS/MIME. Specifically, it has examples of Cryptographic MessageSyntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability forS/MIME and other protocols that rely on CMS.

RFC 4135 Goals of Detecting Network Attachment in IPv6

Authors: JH. Choi, G. Daley.

Date: August 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4135

When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment(DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling.

RFC 4136 OSPF Refresh and Flooding Reduction in Stable Topologies

Authors: P. Pillay-Esnault.

Date: July 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4136

This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies.
Current OSPF behavior requires that all LSAs, except DoNotAge LSAs, to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs in order to reduce protocol traffic in stable topologies.

RFC 4137 State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator

Authors: J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba.

Date: August 2005

Formats: txt pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4137

This document describes a set of state machines for ExtensibleAuthentication Protocol (EAP) peer, EAP stand-alone authenticator(non-pass-through), EAP backend authenticator (for use onAuthentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.
The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAPSwitch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.
The state machine and associated model are informative only.Implementations may achieve the same results using different methods.

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 4139 Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)

Authors: D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong.

Date: July 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4139

The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, includingSynchronous Optical Network (SONET)/Synchronous Digital Hierarchy(SDH) and Optical Transport Networks (OTNs).
This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by theGMPLS signaling protocol to support the capabilities of anAutomatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for theGMPLS signaling protocol to support the ASON functionality.

RFC 4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6)

Authors: H. Soliman, C. Castelluccia, K. El Malki, L. Bellier.

Date: August 2005

Formats: txt html json

Obsoleted by: RFC 5380

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4140

This document introduces extensions to Mobile IPv6 and IPv6 NeighbourDiscovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed.

RFC 4141 SMTP and MIME Extensions for Content Conversion

Authors: K. Toyoda, D. Crocker.

Date: November 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4141

A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred. Such content needs to be converted to an acceptable form, with the same information or constrained information(e.g., changing from color to black and white). In a store-and- forward environment, it may be convenient to have this conversion performed by an intermediary. This specification integrates twoESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries.

RFC 4142 Full-mode Fax Profile for Internet Mail (FFPIM)

Authors: D. Crocker, G. Klyne.

Date: November 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4142

Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users.

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 4144 How to Gain Prominence and Influence in Standards Organizations

Authors: D. Eastlake 3rd.

Date: September 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4144

This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations.

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 4146 Simple New Mail Notification

Authors: R. Gellens.

Date: August 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4146

This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client.
In brief, the server sends the string "nm_notifyuser" CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail.

RFC 4147 Proposed Changes to the Format of the IANA IPv6 Registry

Authors: G. Huston.

Date: August 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4147

This document proposes a revised format for the IANA IPv6 address registries. Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format.The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format.

RFC 4148 IP Performance Metrics (IPPM) Metrics Registry

Authors: E. Stephan.

Date: August 2005

Formats: txt html json

Obsoleted by: RFC 6248

Also: BCP 0108

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4148

This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.
This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.
IANA has been assigned to administer this new registry.

RFC 4149 Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms

Authors: C. Kalbfleisch, R. Cole, D. Romascanu.

Date: August 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4149

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms.

RFC 4150 Transport Performance Metrics MIB

Authors: R. Dietz, R. Cole.

Date: August 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4150

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 monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions.The metrics can be defined through reference to existing IETF, ITU, and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources.

RFC 4151 The 'tag' URI Scheme

Authors: T. Kindberg, S. Hawke.

Date: October 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4151

This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources.

RFC 4152 A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code

Authors: K. Tesink, R. Fox.

Date: August 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4152

This document describes a Uniform Resource Name (URN) namespace(RFC 3406) for the assignment of the Common Language EquipmentIdentifier (CLEI) code, which is used in messages standardized byANSI. The URN namespace is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. TheCLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI code and supplier's product ID (the manufacturer's name and the part number along with its version number).

RFC 4153 XML Voucher: Generic Voucher Language

Authors: K. Fujimura, M. Terada, D. Eastlake 3rd.

Date: September 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4153

This document specifies rules for defining voucher properties in XML syntax. A voucher is a logical entity that represents a right to claim goods or services. A voucher can be used to transfer a wide range of electronic values, including coupons, tickets, loyalty points, and gift certificates, which often have to be processed in the course of payment and/or delivery transactions.

RFC 4154 Voucher Trading System Application Programming Interface (VTS-API)

Authors: M. Terada, K. Fujimura.

Date: September 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4154

This document specifies the Voucher Trading System ApplicationProgramming Interface (VTS-API). The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation. The VTS is a system for securely transferring vouchers; e.g., coupons, tickets, loyalty points, and gift certificates. This process is often necessary in the course of payment and/or delivery transactions.

RFC 4155 The application/mbox Media Type

Authors: E. Hall.

Date: September 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4155

This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations.

RFC 4156 The wais URI Scheme

Authors: P. Hoffman.

Date: August 2005

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 4156

This document specifies the wais Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.

RFC 4157 The prospero URI Scheme

Authors: P. Hoffman.

Date: August 2005

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 4157

This document specifies the prospero Uniform Resource Identifier(URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.

RFC 4158 Internet X.509 Public Key Infrastructure: Certification Path Building

Authors: M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph, R. Nicholas.

Date: September 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4158

This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments.

RFC 4159 Deprecation of "ip6.int"

Authors: G. Huston.

Date: August 2005

Formats: txt html json

Also: BCP 0109

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4159

This document advises of the deprecation of the use of "ip6.int" forStandards Conformant IPv6 implementations.

RFC 4160 Internet Fax Gateway Requirements

Authors: K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, C. Allocchio.

Date: August 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4160

To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an "Internet Fax Gateway" is required. This document provides recommendations for the functionality of Internet FaxGateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN.

RFC 4161 Guidelines for Optional Services for Internet Fax Gateways

Authors: K. Mimura, K. Yokoyama, T. Satoh, K. Watanabe, C. Kanaide.

Date: August 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4161

To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an "Internet Fax Gateway" is required. This document provides guidelines for the optional functionality ofInternet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN.
This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways.

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 4163 RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression

Authors: L-E. Jonsson.

Date: August 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4163

This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression(ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC.

RFC 4164 RObust Header Compression (ROHC): Context Replication for ROHC Profiles

Authors: G. Pelletier.

Date: August 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4164

This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression(ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context.Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows.

RFC 4165 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)

Authors: T. George, B. Bidulock, R. Dantu, H. Schwarzbauer, K. Morneault.

Date: September 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4165

This document defines a protocol supporting the transport ofSignaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol.The SS7 Signaling Points may also use standard SS7 links using theSS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages. The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints.

RFC 4166 Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement

Authors: L. Coene, J. Pastor-Balbas.

Date: February 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4166

This document describes the applicability of the several protocols developed under the signalling transport framework. A description of the main issues regarding the use of the Stream Control TransmissionProtocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given.

RFC 4167 Graceful OSPF Restart Implementation Report

Authors: A. Lindem.

Date: October 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4167

Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as itsOSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol.

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 4169 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2

Authors: V. Torvinen, J. Arkko, M. Naslund.

Date: November 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4169

HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack.

RFC 4170 Tunneling Multiplexed Compressed RTP (TCRTP)

Authors: B. Thompson, T. Koren, D. Wing.

Date: November 2005

Formats: txt html json

Also: BCP 0110

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4170

This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-timeTransport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path.

RFC 4171 Internet Storage Name Service (iSNS)

Authors: J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. Souza.

Date: September 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4171

This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI andFibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof.

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 4176 Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management

Authors: Y. El Mghazli, Ed., T. Nadeau, M. Boucadair, K. Chan, A. Gonguet.

Date: October 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4176

This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document.

RFC 4177 Architectural Approaches to Multi-homing for IPv6

Authors: G. Huston.

Date: September 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4177

This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing.

RFC 4178 The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism

Authors: L. Zhu, P. Leach, K. Jaganathan, W. Ingersoll.

Date: October 2005

Formats: txt html json

Obsoletes: RFC 2478

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4178

This document specifies a negotiation mechanism for the GenericSecurity Service Application Program Interface (GSS-API), which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker that forces the selection of a mechanism not desired by the peers.
This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet.

RFC 4179 Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)

Authors: S. Kang.

Date: October 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4179

This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as music, videos, texts, images, e-books, and other types of digital resources produced or managed by NCA.

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 4183 A Suggested Scheme for DNS Resolution of Networks and Gateways

Authors: E. Warnicke.

Date: September 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4183

This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet.

RFC 4184 RTP Payload Format for AC-3 Audio

Authors: B. Link, T. Hager, J. Flaks.

Date: October 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4184

This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for UnitedStates HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation.

RFC 4185 National and Local Characters for DNS Top Level Domain (TLD) Names

Authors: J. Klensin.

Date: October 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4185

In the context of work on internationalizing the Domain Name System(DNS), there have been extensive discussions about "multilingual" or"internationalized" top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific "multilingual" TLDs in the language(s) and script(s) of that country.

RFC 4186 Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)

Authors: H. Haverinen, Ed., J. Salowey, Ed..

Date: January 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4186

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using theGlobal System for Mobile Communications (GSM) Subscriber IdentityModule (SIM). GSM is a second generation mobile network standard.The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure.

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 4188 Definitions of Managed Objects for Bridges

Authors: K. Norseth, Ed., E. Bell, Ed..

Date: September 2005

Formats: txt html json

Obsoletes: RFC 1493

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4188

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for the support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.
The MIB module presented in this memo is a translation of theBRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.
This memo obsoletes RFC 1493.

RFC 4189 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)

Authors: K. Ono, S. Tachimoto.

Date: October 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4189

A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security.

RFC 4190 Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony

Authors: K. Carlberg, I. Brown, C. Beard.

Date: November 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4190

This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony.We present a series of objectives that reflect a general view of how authorized emergency service, in line with the EmergencyTelecommunications Service (ETS), should be realized within today'sIP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existingIETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space.

RFC 4191 Default Router Preferences and More-Specific Routes

Authors: R. Draves, D. Thaler.

Date: November 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4191

This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more- specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables.

RFC 4192 Procedures for Renumbering an IPv6 Network without a Flag Day

Authors: F. Baker, E. Lear, R. Droms.

Date: September 2005

Formats: txt json html

Updates: RFC 2072

Status: INFORMATIONAL

DOI: 10.17487/RFC 4192

This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix.

RFC 4193 Unique Local IPv6 Unicast Addresses

Authors: R. Hinden, B. Haberman.

Date: October 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4193

This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the globalInternet.

RFC 4194 The S Hexdump Format

Authors: J. Strombergson, L. Walleij, P. Faltstrom.

Date: October 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4194

This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format.

RFC 4195 A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum

Authors: W. Kameyama.

Date: October 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4195

This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime ForumStandards, XML (Extensible Markup Language) Document TypeDefinitions, XML Schemas, Namespaces, and other documents.

RFC 4196 The SEED Cipher Algorithm and Its Use with IPsec

Authors: H.J. Lee, J.H. Yoon, S.L. Lee, J.I. Lee.

Date: October 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4196

This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsecEncapsulating Security Payload (ESP).

RFC 4197 Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks

Authors: M. Riegel, Ed..

Date: October 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4197

This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits.

RFC 4198 A Uniform Resource Name (URN) Namespace for Federated Content

Authors: D. Tessman.

Date: November 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4198

This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections.A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members.

RFC 4201 Link Bundling in MPLS Traffic Engineering (TE)

Authors: K. Kompella, Y. Rekhter, L. Berger.

Date: October 2005

Formats: txt html json

Updates: RFC 3471, RFC 3472, RFC 3473

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4201

For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label&rt; is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document.This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description.

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 4205 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)

Authors: K. Kompella, Ed., Y. Rekhter, Ed..

Date: October 2005

Formats: txt html json

Obsoleted by: RFC 5307

Updates: RFC 3784

Status: INFORMATIONAL

DOI: 10.17487/RFC 4205

This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS).

RFC 4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)

Authors: K. Kompella, Y. Rekhter.

Date: October 2005

Formats: txt 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 4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model

Authors: G. Swallow, J. Drake, H. Ishimatsu, Y. Rekhter.

Date: October 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4208

Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label SwitchedPaths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model.

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 4212 Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols

Authors: M. Blinov, C. Adams.

Date: October 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4212

The Public-Key Infrastructure using X.509 (PKIX) Working Group of theInternet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well.This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and CertificateManagement Messages over CMS (CMC).

RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers

Authors: E. Nordmark, R. Gilligan.

Date: October 2005

Formats: txt json html

Obsoletes: RFC 2893

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4213

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol(IPv4 and IPv6), and configured tunneling provides a means to carryIPv6 packets over unmodified IPv4 routing infrastructures.
This document obsoletes RFC 2893.

RFC 4214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

Authors: F. Templin, T. Gleeson, M. Talwar, D. Thaler.

Date: October 2005

Formats: txt html json

Obsoleted by: RFC 5214

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4214

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connectsIPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model.

RFC 4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks

Authors: J. Wiljakka, Ed..

Date: October 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4215

This document analyzes the transition to IPv6 in Third GenerationPartnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for MobileCommunications (GSM) or Universal Mobile Telecommunications System(UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed.

RFC 4216 MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements

Authors: R. Zhang, Ed., J.-P. Vasseur, Ed..

Date: November 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4216

This document discusses requirements for the support of inter-AS MPLSTraffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios.

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 4218 Threats Relating to IPv6 Multihoming Solutions

Authors: E. Nordmark, T. Li.

Date: October 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4218

This document lists security threats related to IPv6 multihoming.Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.
The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to allIPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work.

RFC 4219 Things Multihoming in IPv6 (MULTI6) Developers Should Think About

Authors: E. Lear.

Date: October 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4219

This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6.The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution.

RFC 4220 Traffic Engineering Link Management Information Base

Authors: M. Dubuc, T. Nadeau, J. Lang.

Date: November 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4220

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document.

RFC 4221 Multiprotocol Label Switching (MPLS) Management Overview

Authors: T. Nadeau, C. Srinivasan, A. Farrel.

Date: November 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4221

A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects ofMultiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.
This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management.

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 4223 Reclassification of RFC 1863 to Historic

Authors: P. Savola.

Date: October 2005

Formats: txt json html

Obsoletes: RFC 1863

Status: INFORMATIONAL

DOI: 10.17487/RFC 4223

This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also obsoletesRFC 1863.

RFC 4224 RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets

Authors: G. Pelletier, L-E. Jonsson, K. Sandlund.

Date: January 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4224

RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols(profiles). One operating assumption for the profiles defined in RFC3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles.

RFC 4225 Mobile IP Version 6 Route Optimization Security Design Background

Authors: P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4225

This document is an account of the rationale behind the Mobile IPv6(MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.
The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs.

RFC 4226 HOTP: An HMAC-Based One-Time Password Algorithm

Authors: D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache, O. Ranen.

Date: December 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4226

This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network(VPN) access, Wi-Fi network logon to transaction-oriented Web applications.
This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations.

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 4228 Requirements for an IETF Draft Submission Toolset

Authors: A. Rousskov.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4228

This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting.

RFC 4229 HTTP Header Field Registrations

Authors: M. Nottingham, J. Mogul.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4229

This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864.

RFC 4230 RSVP Security Properties

Authors: H. Tschofenig, R. Graveman.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4230

This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities.

RFC 4231 Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512

Authors: M. Nystrom.

Date: December 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4231

This document provides test vectors for the HMAC-SHA-224,HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and UniformResource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing.

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 4234 Augmented BNF for Syntax Specifications: ABNF

Authors: D. Crocker, Ed., P. Overell.

Date: October 2005

Formats: txt html json

Obsoletes: RFC 2234

Obsoleted by: RFC 5234

Status: DRAFT STANDARD

DOI: 10.17487/RFC 4234

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 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 4236 HTTP Adaptation with Open Pluggable Edge Services (OPES)

Authors: A. Rousskov, M. Stecher.

Date: November 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4236

Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation.Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES.

RFC 4237 Voice Messaging Directory Service

Authors: G. Vaudreuil.

Date: October 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4237

This document provides details of the Voice Profile for Internet Mail(VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.
The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one fromAnne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission.

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 4239 Internet Voice Messaging (IVM)

Authors: S. McRae, G. Parsons.

Date: November 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4239

This document describes the carriage of voicemail messages overInternet mail as part of a unified messaging infrastructure.
The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet MailVersion 2), but rather an alternative specification for a different application.

RFC 4240 Basic Network Media Services with SIP

Authors: E. Burger, Ed., J. Van Dyke, A. Spitzer.

Date: December 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4240

In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.
This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks.

RFC 4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service

Authors: Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi.

Date: December 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4241

This memo is a digest of the user network interface specification ofNTT Communications' dual stack ADSL access service, which provide aIPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses ofIPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically.

RFC 4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Authors: S. Venaas, T. Chown, B. Volz.

Date: November 2005

Formats: txt html json

Obsoleted by: RFC 8415

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4242

This document describes a Dynamic Host Configuration Protocol forIPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved fromDHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration.

RFC 4243 Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option

Authors: M. Stapp, R. Johnson, T. Palaniappan.

Date: December 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4243

This memo defines a new Vendor-Specific Information suboption for theDynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor- specific information in the DHCP messages it forwards, as configured by its administrator.

RFC 4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information

Authors: M. Barnes, Ed..

Date: November 2005

Formats: txt json html

Obsoleted by: RFC 7044

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4244

This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests.

RFC 4245 High-Level Requirements for Tightly Coupled SIP Conferencing

Authors: O. Levin, R. Even.

Date: November 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4245

This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications.

RFC 4246 International Standard Audiovisual Number (ISAN) URN Definition

Authors: M. Dolan.

Date: February 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4246

The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works. This document is the definition of the formalUniform Resource Name (URN) Namespace Identifier (NID) for ISAN.

RFC 4247 Requirements for Header Compression over MPLS

Authors: J. Ash, B. Goode, J. Hand, R. Zhang.

Date: November 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4247

Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS LabelSwitched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario.

RFC 4248 The telnet URI Scheme

Authors: P. Hoffman.

Date: October 2005

Formats: txt json html

Obsoletes: RFC 1738

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4248

This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.

RFC 4249 Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components

Authors: B. Lilly.

Date: January 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4249

Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer.This memo identifies information useful to implementers of header field generators and parsers.

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 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints

Authors: J. Schlyter, W. Griffin.

Date: January 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4255

This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint.

RFC 4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)

Authors: F. Cusack, M. Forssen.

Date: January 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4256

The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for theSSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s).

RFC 4257 Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks

Authors: G. Bernstein, E. Mannie, V. Sharma, E. Gray.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4257

Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks.This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous DigitalHierarchy (SDH) or Synchronous Optical Networking (SONET) networks.SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed.

RFC 4258 Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)

Authors: D. Brungard, Ed..

Date: November 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4258

The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous DigitalHierarchy (SDH) and Optical Transport Networks (OTNs).
This document concentrates on the routing requirements placed on theGMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T.

RFC 4259 A Framework for Transmission of IP Datagrams over MPEG-2 Networks

Authors: M.-J. Montpetit, G. Fairhurst, H. Clausen, B. Collini-Nocker, H. Linder.

Date: November 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4259

This document describes an architecture for the transport of IPDatagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) andAdvanced Television Systems Committee (ATSC) Standards for DigitalTelevision.
The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS.

RFC 4260 Mobile IPv6 Fast Handovers for 802.11 Networks

Authors: P. McCann.

Date: November 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4260

This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications.

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 4262 X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities

Authors: S. Santesson.

Date: December 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4262

This document defines a certificate extension for inclusion ofSecure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities inX.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIMECapabilities signed attribute in S/MIME messages according to RFC3851.

RFC 4263 Media Subtype Registration for Media Type text/troff

Authors: B. Lilly.

Date: January 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4263

A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described.

RFC 4264 BGP Wedgies

Authors: T. Griffin, G. Huston.

Date: November 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4264

It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable. Also, the stable state whereBGP converges may be selected by BGP in a non-deterministic manner.These stable, but unintended, BGP states are termed here "BGPWedgies".

RFC 4265 Definition of Textual Conventions for Virtual Private Network (VPN) Management

Authors: B. Schliesser, T. Nadeau.

Date: November 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4265

This document describes Textual Conventions used for managing VirtualPrivate Networks (VPNs).

RFC 4266 The gopher URI Scheme

Authors: P. Hoffman.

Date: November 2005

Formats: txt html json

Obsoletes: RFC 1738

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4266

This document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.

RFC 4267 The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml

Authors: M. Froumentin.

Date: November 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4267

This document defines the media types for the languages of the W3CSpeech Interface Framework, as designed by the Voice Browser WorkingGroup in the following specifications: the Voice Extensible MarkupLanguage (VoiceXML), the Speech Synthesis Markup Language (SSML), theSpeech Recognition Grammar Specification (SRGS), the Call Control XML(CCXML), and the Pronunciation Lexicon Specification (PLS).

RFC 4268 Entity State MIB

Authors: S. Chisholm, D. Perkins.

Date: November 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4268

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 extensions to the Entity MIB to provide information about the state of physical entities.
In addition, this memo defines a set of Textual Conventions to represent various states of an entity. The intent is that theseTextual Conventions will be imported and used in MIB modules that would otherwise define their own representations.

RFC 4269 The SEED Encryption Algorithm

Authors: H.J. Lee, S.J. Lee, J.H. Yoon, D.H. Cheon, J.I. Lee.

Date: December 2005

Formats: txt json html

Obsoletes: RFC 4009

Status: INFORMATIONAL

DOI: 10.17487/RFC 4269

This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).
This document obsoletes RFC 4009.

RFC 4270 Attacks on Cryptographic Hashes in Internet Protocols

Authors: P. Hoffman, B. Schneier.

Date: November 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4270

Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers.

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 4272 BGP Security Vulnerabilities Analysis

Authors: S. Murphy.

Date: January 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4272

Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.
This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets.

RFC 4273 Definitions of Managed Objects for BGP-4

Authors: J. Haas, Ed., S. Hares, Ed..

Date: January 2006

Formats: txt html json

Obsoletes: RFC 1269, RFC 1657

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4273

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet communityIn particular, it describes managed objects used for managing theBorder Gateway Protocol Version 4 or lower.
The origin of this memo is from RFC 1269 "Definitions of ManagedObjects for the Border Gateway Protocol (Version 3)", which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents.
This memo is intended to document deployed implementations of thisMIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of theBGP protocol and its extensions.
This document obsoletes RFC 1269 and RFC 1657.

RFC 4274 BGP-4 Protocol Analysis

Authors: D. Meyer, K. Patel.

Date: January 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4274

The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance.

RFC 4275 BGP-4 MIB Implementation Survey

Authors: S. Hares, D. Hares.

Date: January 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4275

This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification.

RFC 4276 BGP-4 Implementation Report

Authors: S. Hares, A. Retana.

Date: January 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4276

This document reports the results of the BGP-4 implementation survey.The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, andNextHop) and brief information from three that did not (Avici, DataConnection Ltd., and Nokia).
The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on.

RFC 4277 Experience with the BGP-4 Protocol

Authors: D. McPherson, K. Patel.

Date: January 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4277

The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted forStandard.

RFC 4278 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification

Authors: S. Bellovin, A. Zinin.

Date: January 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4278

The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection ofBGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level.

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 4280 Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers

Authors: K. Chowdhury, P. Yegani, L. Madour.

Date: November 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4280

This document defines new options to discover the Broadcast andMulticast Service (BCMCS) controller in an IP network. BCMCS is being developed for Third generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service. Dynamic Host ConfigurationProtocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes.

RFC 4281 The Codecs Parameter for "Bucket" Media Types

Authors: R. Gellens, D. Singer, P. Frojdh.

Date: November 2005

Formats: txt json html

Obsoleted by: RFC 6381

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4281

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from theContent-Type alone if the content can be rendered.
This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within.
By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action(such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.)

RFC 4282 The Network Access Identifier

Authors: B. Aboba, M. Beadles, J. Arkko, P. Eronen.

Date: December 2005

Formats: txt html json

Obsoletes: RFC 2486

Obsoleted by: RFC 7542

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4282

In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple InternetService Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC.

RFC 4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6)

Authors: A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury.

Date: November 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4283

Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name(FQDN), International Mobile Station Identifier (IMSI), and MobileSubscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header.

RFC 4284 Identity Selection Hints for the Extensible Authentication Protocol (EAP)

Authors: F. Adrangi, V. Lortz, F. Bari, P. Eronen.

Date: January 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4284

The Extensible Authentication Protocol (EAP) is defined in RFC 3748.This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier(NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.
The mechanism defined in this document is limited in its scalability.It is intended for access networks that have a small to moderate number of direct roaming partners.

RFC 4285 Authentication Protocol for Mobile IPv6

Authors: A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury.

Date: January 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4285

IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between aMobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes andHome Agents. The alternate method defined here consists of aMIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages.

RFC 4286 Multicast Router Discovery

Authors: B. Haberman, J. Martin.

Date: December 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4286

The concept of Internet Group Management Protocol (IGMP) andMulticast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.
This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast RouterDiscovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols.

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 4288 Media Type Specifications and Registration Procedures

Authors: N. Freed, J. Klensin.

Date: December 2005

Formats: txt json html

Obsoletes: RFC 2048

Obsoleted by: RFC 6838

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4288

This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols.

RFC 4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures

Authors: N. Freed, J. Klensin.

Date: December 2005

Formats: txt json html

Obsoletes: RFC 2048

Also: BCP 0013

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4289

This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings.

RFC 4290 Suggested Practices for Registration of Internationalized Domain Names (IDN)

Authors: J. Klensin.

Date: December 2005

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4290

This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar- looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed forChinese, Japanese, and Korean domain names.

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 4292 IP Forwarding Table MIB

Authors: B. Haberman.

Date: April 2006

Formats: txt html json

Obsoletes: RFC 2096

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4292

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version- independent manner. This document obsoletes RFC 2096.

RFC 4293 Management Information Base for the Internet Protocol (IP)

Authors: S. Routhier, Ed..

Date: April 2006

Formats: txt html json

Obsoletes: RFC 2011, RFC 2465, RFC 2466

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4293

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 implementations of the Internet Protocol (IP) in an IP version independent manner.This memo obsoletes RFCs 2011, 2465, and 2466.

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 4295 Mobile IPv6 Management Information Base

Authors: G. Keeni, K. Koide, K. Nagami, S. Gundavelli.

Date: April 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4295

This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in theInternet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity.

RFC 4296 The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols

Authors: S. Bailey, T. Talpey.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4296

This document defines an abstract architecture for Direct DataPlacement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements.

RFC 4297 Remote Direct Memory Access (RDMA) over IP Problem Statement

Authors: A. Romanow, J. Mogul, T. Talpey, S. Bailey.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4297

Overhead due to the movement of user data in the end-system networkI/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and theInternet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.
This document examines this overhead, and addresses an architectural,IP-based "copy avoidance" solution for its elimination, by enablingRemote Direct Memory Access (RDMA).

RFC 4298 RTP Payload Format for BroadVoice Speech Codecs

Authors: J.-H. Chen, W. Lee, J. Thyssen.

Date: December 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4298

This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, calledBroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice withMIME and the Session Description Protocol (SDP).

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 4302 IP Authentication Header

Authors: S. Kent.

Date: December 2005

Formats: txt html json

Obsoletes: RFC 2402

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4302

This document describes an updated version of the IP AuthenticationHeader (AH), which is designed to provide authentication services inIPv4 and IPv6. This document obsoletes RFC 2402 (November 1998).

RFC 4303 IP Encapsulating Security Payload (ESP)

Authors: S. Kent.

Date: December 2005

Formats: txt html json

Obsoletes: RFC 2406

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4303

This document describes an updated version of the EncapsulatingSecurity Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998).

RFC 4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)

Authors: S. Kent.

Date: December 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4304

The IP Security Authentication Header (AH) and Encapsulating SecurityPayload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain ofInterpretation (DOI) for the Internet Security Association and KeyManagement Protocol (ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64- bit) sequence numbers (ESNs) for a particular AH or ESP security association.

RFC 4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

Authors: D. Eastlake 3rd.

Date: December 2005

Formats: txt json html

Obsoletes: RFC 2402, RFC 2406

Obsoleted by: RFC 4835

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4305

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The EncapsulatingSecurity Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec SecurityAssociation (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time.

RFC 4306 Internet Key Exchange (IKEv2) Protocol

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 4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)

Authors: J. Schiller.

Date: December 2005

Formats: txt html json

Obsoleted by: RFC 8247

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4307

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet KeyExchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time.

RFC 4308 Cryptographic Suites for IPsec

Authors: P. Hoffman.

Date: December 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4308

The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2.

RFC 4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)

Authors: R. Housley.

Date: December 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4309

This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity.

RFC 4310 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

Authors: S. Hollenbeck.

Date: December 2005

Formats: txt json html

Obsoleted by: RFC 5910

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4310

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain NameSystem security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions.

RFC 4311 IPv6 Host-to-Router Load Sharing

Authors: R. Hinden, D. Thaler.

Date: November 2005

Formats: txt json html

Updates: RFC 2461

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4311

The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion.

RFC 4312 The Camellia Cipher Algorithm and Its Use With IPsec

Authors: A. Kato, S. Moriai, M. Kanda.

Date: December 2005

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4312

This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicitInitialization Vector, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).

RFC 4313 Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources

Authors: D. Oran.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4313

This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and RealTime Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address.

RFC 4314 IMAP4 Access Control List (ACL) Extension

Authors: A. Melnikov.

Date: December 2005

Formats: txt json html

Obsoletes: RFC 2086

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4314

The Access Control List (ACL) extension (RFC 2086) of the InternetMessage Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.
This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands.

RFC 4315 Internet Message Access Protocol (IMAP) - UIDPLUS extension

Authors: M. Crispin.

Date: December 2005

Formats: txt json html

Obsoletes: RFC 2359

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4315

The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients.

RFC 4316 Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties

Authors: J. Reschke.

Date: December 2005

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4316

This specification extends the Web Distributed Authoring andVersioning Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information.

RFC 4317 Session Description Protocol (SDP) Offer/Answer Examples

Authors: A. Johnston, R. Sparks.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4317

This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. CommonThird Party Call Control (3pcc) examples are also given.

RFC 4318 Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol

Authors: D. Levi, D. Harrington.

Date: December 2005

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4318

This memo defines an SMIv2 MIB module for managing the Rapid SpanningTree capability defined by the IEEE P802.1t and P802.1w amendments toIEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments.

RFC 4319 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines

Authors: C. Sikes, B. Ray, R. Abbi.

Date: December 2005

Formats: txt json html

Obsoletes: RFC 3276

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4319

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-RateDigital Subscriber Line (DSL) - 2nd generation (HDSL2) andSingle-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces.This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276). This document obsoletes RFC 3276.

RFC 4320 Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction

Authors: R. Sparks.

Date: January 2006

Formats: txt json html

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4320

This document describes modifications to the Session InitiationProtocol (SIP) to address problems that have been identified with theSIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding.These changes update behavior defined in RFC 3261.

RFC 4321 Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction

Authors: R. Sparks.

Date: January 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4321

This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction.

RFC 4322 Opportunistic Encryption using the Internet Key Exchange (IKE)

Authors: M. Richardson, D.H. Redelmeier.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4322

This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet KeyExchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.
As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance.

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 4324 Calendar Access Protocol (CAP)

Authors: D. Royer, G. Babics, S. Mansour.

Date: December 2005

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4324

The Calendar Access Protocol (CAP) described in this memo permits aCalendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols.

RFC 4325 Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension

Authors: S. Santesson, R. Housley.

Date: December 2005

Formats: txt json html

Obsoleted by: RFC 5280

Updates: RFC 3280

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4325

This document updates RFC 3280 by defining the Authority InformationAccess Certificate Revocation List (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates.

RFC 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 4327 Link Management Protocol (LMP) Management Information Base (MIB)

Authors: M. Dubuc, T. Nadeau, J. Lang, E. McGinnis.

Date: January 2006

Formats: txt html json

Obsoleted by: RFC 4631

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4327

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling the LinkManagement Protocol (LMP).

RFC 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 4329 Scripting Media Types

Authors: B. Hoehrmann.

Date: April 2006

Formats: txt json html

Obsoleted by: RFC 9239

Status: INFORMATIONAL

DOI: 10.17487/RFC 4329

This document describes the registration of media types for theECMAScript and JavaScript programming languages and conformance requirements for implementations of these types.

RFC 4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI

Authors: D. Mills.

Date: January 2006

Formats: txt json html

Obsoletes: RFC 2030, RFC 1769

Obsoleted by: RFC 5905

Status: INFORMATIONAL

DOI: 10.17487/RFC 4330

This memorandum describes the Simple Network Time Protocol Version 4(SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based onRFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.
This memorandum obsoletes RFC 1769, which describes SNTP Version 3(SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) andSNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation ofSNTP.

RFC 4331 Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections

Authors: B. Korver, L. Dusseault.

Date: February 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4331

Web Distributed Authoring and Versioning (WebDAV) servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories.

RFC 4332 Cisco's Mobile IPv4 Host Configuration Extensions

Authors: K. Leung, A. Patel, G. Tsirtsis, E. Klovning.

Date: December 2005

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4332

An IP device requires basic host configuration to be able to communicate. For example, it will typically require an IP address and the address of a DNS server. This information is configured statically or obtained dynamically using Dynamic Host ConfigurationProtocol (DHCP) or Point-to-Point Protocol/IP Control Protocol(PPP/IPCP). However, both DHCP and PPP/IPCP provide host configuration based on the access network. In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as a foreign network. The information to configure the host needs to be based on the home network. This document describes the Cisco vendor-specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages.

RFC 4333 The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process

Authors: G. Huston, Ed., B. Wijnen, Ed..

Date: December 2005

Formats: txt html json

Obsoleted by: RFC 8711

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4333

This memo outlines the guidelines for selection of members of theIETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG.

RFC 4334 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)

Authors: R. Housley, T. Moore.

Date: February 2006

Formats: txt json html

Obsoletes: RFC 3770

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4334

This document defines two Extensible Authentication Protocol (EAP) extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RFC 3770.

RFC 4335 The Secure Shell (SSH) Session Channel Break Extension

Authors: J. Galbraith, P. Remaker.

Date: January 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4335

The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session.

RFC 4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP)

Authors: S. Floyd, M. Handley, E. Kohler.

Date: March 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4336

This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games.

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 4339 IPv6 Host Configuration of DNS Server Information Approaches

Authors: J. Jeong, Ed..

Date: February 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4339

This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise,3GPP, and unmanaged networks) considering multi-solution resolution.

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 4344 The Secure Shell (SSH) Transport Layer Encryption Modes

Authors: M. Bellare, T. Kohno, C. Namprempre.

Date: January 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4344

Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks.
This document describes new symmetric encryption methods for theSecure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey.

RFC 4345 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol

Authors: B. Harris.

Date: January 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4345

This document specifies methods of using the Arcfour cipher in theSecure Shell (SSH) protocol that mitigate the weakness of the cipher's key-scheduling algorithm.

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 4350 A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government

Authors: F. Hendrikx, C. Wallis.

Date: February 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4350

This document describes a Uniform Resource Name (URN) NamespaceIdentification (NID)convention as prescribed by the World Wide WebConsortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New ZealandGovernment.

RFC 4351 Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream

Authors: G. Hellstrom, P. Jones.

Date: January 2006

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 4351

This memo 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 audio and text data within a single RTP session.
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 4352 RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec

Authors: J. Sjoberg, M. Westerlund, A. Lakaniemi, S. Wenger.

Date: January 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4352

This document specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB speech codec. It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech. A media type registration for AMR-WB+ is included in this specification.

RFC 4353 A Framework for Conferencing with the Session Initiation Protocol (SIP)

Authors: J. Rosenberg.

Date: February 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4353

The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents.These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi- party conferencing.

RFC 4354 A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service

Authors: M. Garcia-Martin.

Date: January 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4354

The Open Mobile Alliance (OMA) is defining the Push-to-talk overCellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet.

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 4356 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail

Authors: R. Gellens.

Date: January 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4356

The cellular telephone industry has defined a service known as theMultimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail.
One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements.
This document specifies how to exchange messages between these two services, including mapping information elements as used in MMSX-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers.

RFC 4357 Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms

Authors: V. Popov, I. Kurepkin, S. Leontiev.

Date: January 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4357

This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89,GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use inInternet applications.

RFC 4358 A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA)

Authors: D. Smith.

Date: January 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4358

This document describes the Namespace Identifier (NID) for UniformResource Namespace (URN) resources published by the Open MobileAlliance (OMA). OMA defines and manages resources that utilize thisURN name model. Management activities for these and other resource types are provided by the Open Mobile Naming Authority (OMNA).

RFC 4359 The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)

Authors: B. Weis.

Date: January 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4359

This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP EncapsulatingSecurity Payload (ESP) as described in RFC 4303 and the revised IPAuthentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet.

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 4363 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions

Authors: D. Levi, D. Harrington.

Date: January 2006

Formats: txt json html

Obsoletes: RFC 2674

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4363

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MACBridges and the IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 andP802.1t-2001 (TM). The other MIB module defines objects for managingVLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v(TM).
Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.
This memo supplements RFC 4188 and obsoletes RFC 2674.

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 4365 Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)

Authors: E. Rosen.

Date: February 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4365

This document provides an Applicability Statement for the VirtualPrivate Network (VPN) solution described in RFC 4364 and other documents listed in the References section.

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 4367 What's in a Name: False Assumptions about DNS Names

Authors: J. Rosenberg, Ed., IAB.

Date: February 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4367

The Domain Name System (DNS) provides an essential service on theInternet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform ResourceIdentifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided.

RFC 4368 Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition

Authors: T. Nadeau, S. Hegde.

Date: January 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4368

This memo defines two MIB modules and corresponding MIB ObjectDefinitions that describe how label-switching-controlled Frame-Relay and Asynchronous Transfer Mode (ATM) interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB andMPLS-TE-STD-MIB.

RFC 4369 Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP)

Authors: K. Gibbons, C. Monia, J. Tseng, F. Travostino.

Date: January 2006

Formats: txt html json

Obsoleted by: RFC 6173

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4369

The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP.

RFC 4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control

Authors: R. Weltman.

Date: February 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4370

This document defines the Lightweight Directory Access Protocol(LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection.

RFC 4371 BCP 101 Update for IPR Trust

Authors: B. Carpenter, Ed., L. Lynch, Ed..

Date: January 2006

Formats: txt html json

Obsoleted by: RFC 8714

Updates: RFC 4071

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4371

This document updates BCP 101 to take account of the new IETFIntellectual Property Trust.

RFC 4372 Chargeable User Identity

Authors: F. Adrangi, A. Lior, J. Korhonen, J. Loughney.

Date: January 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4372

This document describes a new Remote Authentication Dial-In UserService (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network.

RFC 4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)

Authors: R. Harrison, J. Sermersheim, Y. Dong.

Date: January 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4373

The Lightweight Directory Access Protocol (LDAP) BulkUpdate/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication.
The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server.

RFC 4374 The application/xv+xml Media Type

Authors: G. McCobb.

Date: January 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4374

This document describes the registration of the MIME sub-type application/xv+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents.

RFC 4375 Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain

Authors: K. Carlberg.

Date: January 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4375

This document presents a list of requirements in support of EmergencyTelecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document.

RFC 4376 Requirements for Floor Control Protocols

Authors: P. Koskelainen, J. Ott, H. Schulzrinne, X. Wu.

Date: February 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4376

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 defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework.

RFC 4377 Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks

Authors: T. Nadeau, M. Morrow, G. Swallow, D. Allan, S. Matsushima.

Date: February 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4377

This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks.

RFC 4378 A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)

Authors: D. Allan, Ed., T. Nadeau, Ed..

Date: February 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4378

This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-ProtocolLabel Switching (MPLS). The document is structured to outline howOperations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS.

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 4381 Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)

Authors: M. Behringer.

Date: February 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4381

This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users.
The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode(ATM) or Frame Relay.

RFC 4382 MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base

Authors: T. Nadeau, Ed., H. van der Linde, Ed..

Date: February 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4382

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 to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual PrivateNetworks on a Multiprotocol Label Switching (MPLS) Label SwitchingRouter (LSR) supporting this feature.

RFC 4383 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)

Authors: M. Baugher, E. Carrara.

Date: February 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4383

This memo describes the use of the Timed Efficient Stream Loss- tolerant Authentication (RFC 4082) transform within the Secure Real- time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams.

RFC 4384 BGP Communities for Data Collection

Authors: D. Meyer.

Date: February 2006

Formats: txt html json

Also: BCP 0114

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4384

BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers. With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard (outbound) communities and their encodings for export to BGP route collectors.

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 4389 Neighbor Discovery Proxies (ND Proxy)

Authors: D. Thaler, M. Talwar, C. Patel.

Date: April 2006

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4389

Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances.

RFC 4390 Dynamic Host Configuration Protocol (DHCP) over InfiniBand

Authors: V. Kashyap.

Date: April 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4390

IP over Infiniband (IPoIB) link-layer address is 20 octets long.This is larger than the 16 octets reserved for the hardware address in a Dynamic Host Configuration Protocol/Bootstrap Protocol(DHCP/BOOTP) message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IPoIB network.This document describes the use of DHCP message fields when implementing DHCP over IPoIB.

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 4392 IP over InfiniBand (IPoIB) Architecture

Authors: V. Kashyap.

Date: April 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4392

InfiniBand is a high-speed, channel-based interconnect between systems and devices.
This document presents an overview of the InfiniBand architecture.It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents.

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 4394 A Transport Network View of the Link Management Protocol (LMP)

Authors: D. Fedyk, O. Aboul-Magd, D. Brungard, J. Lang, D. Papadimitriou.

Date: February 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4394

The Link Management Protocol (LMP) has been developed as part of theGeneralized MPLS (GMPLS) protocol suite to manage Traffic Engineering(TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths(LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International TelecommunicationUnion (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically SwitchedOptical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T.

RFC 4395 Guidelines and Registration Procedures for New URI Schemes

Authors: T. Hansen, T. Hardie, L. Masinter.

Date: February 2006

Formats: txt html json

Obsoletes: RFC 2717, RFC 2718

Obsoleted by: RFC 7595

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4395

This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718.

RFC 4396 RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text

Authors: J. Rey, Y. Matsui.

Date: February 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4396

This document specifies an RTP payload format for the transmission of3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file. Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations. In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified.

RFC 4397 A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture

Authors: I. Bryskin, A. Farrel.

Date: February 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4397

Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths(LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON).
This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture.
It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context.

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 4401 A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)

Authors: N. Williams.

Date: February 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4401

This document defines a Pseudo-Random Function (PRF) extension to theGeneric Security Service Application Program Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that do not or cannot use GSS-API per-message message integrity check (MIC) and wrap tokens for session protection.

RFC 4402 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism

Authors: N. Williams.

Date: February 2006

Formats: txt json html

Obsoleted by: RFC 7802

Status: HISTORIC

DOI: 10.17487/RFC 4402

This document defines the Pseudo-Random Function (PRF) for theKerberos V mechanism for the Generic Security Service ApplicationProgram Interface (GSS-API), based on the PRF defined for theKerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context.

RFC 4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)

Authors: B. Bergeson, K. Boogert, V. Nanjundaswamy.

Date: February 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4403

This document defines the Lightweight Directory Access Protocol(LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory.

RFC 4404 Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP)

Authors: R. Natarajan, A. Rijhsinghani.

Date: February 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4404

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 Fibre Channel OverTCP/IP (FCIP) entities, which are used to interconnect Fibre Channel(FC) fabrics with IP networks.

RFC 4405 SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message

Authors: E. Allman, H. Katz.

Date: April 2006

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 4405

This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain.

RFC 4406 Sender ID: Authenticating E-Mail

Authors: J. Lyon, M. Wong.

Date: April 2006

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 4406

Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address.

RFC 4407 Purported Responsible Address in E-Mail Messages

Authors: J. Lyon.

Date: April 2006

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 4407

This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).

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 4409 Message Submission for Mail

Authors: R. Gellens, J. Klensin.

Date: April 2006

Formats: txt html json

Obsoletes: RFC 2476

Obsoleted by: RFC 6409

Status: DRAFT STANDARD

DOI: 10.17487/RFC 4409

This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
Message relay and final delivery are unaffected, and continue to useSMTP over port 25.
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements.

RFC 4410 Selectively Reliable Multicast Protocol (SRMP)

Authors: M. Pullen, F. Zhao, D. Cohen.

Date: February 2006

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4410

The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best- effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and aSelectively Reliable Transport (SRT) sublayer. Selection between reliable and best-effort messages is performed by the application.

RFC 4411 Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events

Authors: J. Polk.

Date: February 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4411

This document proposes an IANA Registration extension to the SessionInitiation Protocol (SIP) Reason Header to be included in a BYEMethod Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol(RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred.

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 4413 TCP/IP Field Behavior

Authors: M. West, S. McCann.

Date: March 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4413

This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers.

RFC 4414 An ENUM Registry Type for the Internet Registry Information Service (IRIS)

Authors: A. Newton.

Date: February 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4414

This document describes an Internet Registry Information Service(IRIS) registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries.

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 4416 Goals for Internet Messaging to Support Diverse Service Environments

Authors: J. Wong, Ed..

Date: February 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4416

This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.
The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements toInternet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.
The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments-- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.
The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed.

RFC 4417 Report of the 2004 IAB Messaging Workshop

Authors: P. Resnick, Ed., P. Saint-Andre, Ed..

Date: February 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4417

This document reports the outcome of a workshop held by the InternetArchitecture Board (IAB) on the future of Internet messaging. The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA.The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done. This report summarizes the discussions and conclusions of the workshop and of the IAB.

RFC 4418 UMAC: Message Authentication Code using Universal Hashing

Authors: T. Krovetz, Ed..

Date: March 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4418

This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors.Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines.
To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal "cryptographic" component is a block cipher used to generate the pseudorandom pads and internal key material.

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 4420 Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)

Authors: A. Farrel, Ed., D. Papadimitriou, J.-P. Vasseur, A. Ayyangar.

Date: February 2006

Formats: txt html json

Obsoleted by: RFC 5420

Updates: RFC 3209, RFC 3473

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4420

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions. This protocol includes an object(the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.
This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.
The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and toGMPLS non-PSC LSPs.

RFC 4421 RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes

Authors: C. Perkins.

Date: February 2006

Formats: txt html json

Updates: RFC 4175

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4421

The RFC Payload Format for Uncompressed Video, RFC 4175, defines a scheme to packetise uncompressed, studio-quality, video streams for transport using RTP. This memo extends the format to support additional colour sampling modes.

RFC 4422 Simple Authentication and Security Layer (SASL)

Authors: A. Melnikov, Ed., K. Zeilenga, Ed..

Date: June 2006

Formats: txt json html

Obsoletes: RFC 2222

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4422

The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms.The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms.The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.
This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.
This document obsoletes RFC 2222.

RFC 4423 Host Identity Protocol (HIP) Architecture

Authors: R. Moskowitz, P. Nikander.

Date: May 2006

Formats: txt json html

Obsoleted by: RFC 9063

Status: INFORMATIONAL

DOI: 10.17487/RFC 4423

This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, theHost Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since.This document represents one stable point in that evolution of understanding.

RFC 4424 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec

Authors: S. Ahmadi.

Date: February 2006

Formats: txt html json

Updates: RFC 4348

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4424

This document is an addendum to RFC 4348, which specifies the RTP payload format for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document specifies some updates in RFC 4348 to enable support for the new operating mode of VMR-WB standard (i.e.,VMR-WB mode 4). These updates do not affect the existing modes ofVMR-WB already specified in RFC 4348.
The payload formats and their associated parameters, as well as all provisions, restrictions, use cases, features, etc., that are specified in RFC 4348 are applicable to the new operating mode with no exception.

RFC 4425 RTP Payload Format for Video Codec 1 (VC-1)

Authors: A. Klemets.

Date: February 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4425

This memo specifies an RTP payload format for encapsulating VideoCodec 1 (VC-1) compressed bit streams, as defined by the Society ofMotion Picture and Television Engineers (SMPTE) standard, SMPTE 421M.SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television.

RFC 4426 Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification

Authors: J. Lang, Ed., B. Rajagopalan, Ed., D. Papadimitriou, Ed..

Date: March 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4426

This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol LabelSwitching (GMPLS)-based recovery (i.e., protection and restoration).Protocol specific formats and mechanisms will be described in companion documents.

RFC 4427 Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)

Authors: E. Mannie, Ed., D. Papadimitriou, Ed..

Date: March 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4427

This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS.

RFC 4428 Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)

Authors: D. Papadimitriou, Ed., E. Mannie, Ed..

Date: March 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4428

This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects.

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 4430 Kerberized Internet Negotiation of Keys (KINK)

Authors: S. Sakane, K. Kamada, M. Thomas, J. Vilhuber.

Date: March 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4430

This document describes the Kerberized Internet Negotiation of Keys(KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of theInternet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations.

RFC 4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record

Authors: M. Andrews, S. Weiler.

Date: February 2006

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 4431

This document defines a new DNS resource record, called the DNSSECLookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain.

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 4433 Mobile IPv4 Dynamic Home Agent (HA) Assignment

Authors: M. Kulkarni, A. Patel, K. Leung.

Date: March 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4433

Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN). This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a MobileIP session while allowing any suitable method for HA selection.

RFC 4434 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)

Authors: P. Hoffman.

Date: February 2006

Formats: txt html json

Obsoletes: RFC 3664

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4434

Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard(AES). This document describes such an algorithm, calledAES-XCBC-PRF-128.

RFC 4435 A Framework for the Usage of Internet Media Guides (IMGs)

Authors: Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, H. Schulzrinne.

Date: April 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4435

This document defines a framework for the delivery of Internet MediaGuides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol(SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure.

RFC 4436 Detecting Network Attachment in IPv4 (DNAv4)

Authors: B. Aboba, J. Carlson, S. Cheshire.

Date: March 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4436

The time required to detect movement between networks and to obtain(or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment forIPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment.

RFC 4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources

Authors: J. Whitehead, G. Clemm, J. Reschke, Ed..

Date: March 2006

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4437

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx(Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.

RFC 4438 Fibre-Channel Name Server MIB

Authors: C. DeSanti, V. Gaonkar, H.K. Vivek, K. McCloghrie, S. Gai.

Date: April 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4438

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 information related to the Name Server function of a Fibre Channel network. The FibreChannel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes.

RFC 4439 Fibre Channel Fabric Address Manager MIB

Authors: C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai.

Date: March 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4439

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 information related to a Fibre Channel network's Fabric Address Manager.

RFC 4440 IAB Thoughts on the Role of the Internet Research Task Force (IRTF)

Authors: S. Floyd, Ed., V. Paxson, Ed., A. Falk, Ed., IAB.

Date: March 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4440

This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of theIRTF.

RFC 4441 The IEEE 802/IETF Relationship

Authors: B. Aboba, Ed..

Date: March 2006

Formats: txt json html

Obsoleted by: RFC 7241

Status: INFORMATIONAL

DOI: 10.17487/RFC 4441

Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs andAuthentication, Authorization, and Accounting (AAA) applications.This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history.

RFC 4442 Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)

Authors: S. Fries, H. Tschofenig.

Date: March 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4442

TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios.TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized inTESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios whereSRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.
This document specifies payloads for the Multimedia Internet Keying(MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast.

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 4444 Management Information Base for Intermediate System to Intermediate System (IS-IS)

Authors: J. Parker, Ed..

Date: April 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4444

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.Specifically, this document describes a MIB for the IntermediateSystem to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks.

RFC 4445 A Proposed Media Delivery Index (MDI)

Authors: J. Welch, J. Clark.

Date: April 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4445

This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media,MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media.
The MDI measurement defined in this memo is intended for Information only.

RFC 4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)

Authors: L. Martini.

Date: April 2006

Formats: txt html json

Also: BCP 0116

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4446

This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in thePseudo Wire Edge to Edge (PWE3) working group. Detailed IANA allocation instructions are also included in this document.

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 4449 Securing Mobile IPv6 Route Optimization Using a Static Shared Key

Authors: C. Perkins.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4449

A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates.

RFC 4450 Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents

Authors: E. Lear, H. Alvestrand.

Date: March 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4450

This memo documents an experiment to review and classify ProposedStandards as not reflecting documented practice within the world today. The results identify a set of documents that were marked asProposed Standards that are now reclassified as Historic.

RFC 4451 BGP MULTI_EXIT_DISC (MED) Considerations

Authors: D. McPherson, V. Gill.

Date: March 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4451

The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies.
This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar.

RFC 4452 The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces

Authors: H. Van de Sompel, T. Hammond, E. Neylon, S. Weibel.

Date: April 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4452

This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces.Namespaces participating in the "info" URI scheme are regulated by an"info" Registry mechanism.

RFC 4453 Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)

Authors: J. Rosenberg, G. Camarillo, Ed., D. Willis.

Date: April 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4453

The Session Initiation Protocol (SIP) supports communications across many media types, 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 spam and denial-of-service attacks.This document identifies a set of requirements for extensions to SIP that add consent-based communications.

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 4455 Definition of Managed Objects for Small Computer System Interface (SCSI) Entities

Authors: M. Hallak-Stamler, M. Bakke, Y. Lederman, M. Krueger, K. McCloghrie.

Date: April 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4455

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 Small Computer SystemInterface (SCSI) entities, independently of the interconnect subsystem layer.

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 4457 The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)

Authors: G. Camarillo, G. Blanco.

Date: April 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4457

This document specifies the Session Initiation Protocol (SIP)P-User-Database Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP MultimediaSubsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request.

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 4459 MTU and Fragmentation Issues with In-the-Network Tunneling

Authors: P. Savola.

Date: April 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4459

Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided.This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length.

RFC 4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues

Authors: R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen.

Date: April 2006

Formats: txt json html

Obsoleted by: RFC 9260

Status: INFORMATIONAL

DOI: 10.17487/RFC 4460

This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied.In addition to the delta, a description of the problem and the details of the solution are also provided.

RFC 4461 Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)

Authors: S. Yasukawa, Ed..

Date: April 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4461

This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE)Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).
There is no intent to specify solution-specific details or application-specific requirements in this document.
The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), TimeDivision Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS.

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 4463 A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks

Authors: S. Shanmugham, P. Monaco, B. Eberman.

Date: April 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4463

This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for furtherIETF development in this area.
MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (SessionInitiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms likeRTP (Real Time Protocol).

RFC 4464 Signaling Compression (SigComp) Users' Guide

Authors: A. Surtees, M. West.

Date: May 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4464

This document provides an informational guide for users of theSignaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets.

RFC 4465 Signaling Compression (SigComp) Torture Tests

Authors: A. Surtees, M. West.

Date: June 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4465

This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler.

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 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing

Authors: S. Weiler, J. Ihren.

Date: April 2006

Formats: txt json html

Updates: RFC 4035, RFC 4034

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4470

This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone.

RFC 4471 Derivation of DNS Name Predecessor and Successor

Authors: G. Sisson, B. Laurie.

Date: September 2006

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4471

This document describes two methods for deriving the canonically- ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone.

RFC 4472 Operational Considerations and Issues with IPv6 DNS

Authors: A. Durand, J. Ihren, P. Savola.

Date: April 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4472

This memo presents operational considerations and issues with IPv6Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS.

RFC 4473 Requirements for Internet Media Guides (IMGs)

Authors: Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. Schulzrinne.

Date: May 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4473

This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery.

RFC 4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)

Authors: J. Peterson, C. Jennings.

Date: August 2006

Formats: txt json html

Obsoleted by: RFC 8224

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4474

The existing security mechanisms in the Session Initiation Protocol(SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer.

RFC 4475 Session Initiation Protocol (SIP) Torture Test Messages

Authors: R. Sparks, Ed., A. Hawrylyshen, A. Johnston, J. Rosenberg, H. Schulzrinne.

Date: May 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4475

This informational document gives examples of Session InitiationProtocol (SIP) test messages designed to exercise and "torture" a SIP implementation.

RFC 4476 Attribute Certificate (AC) Policies Extension

Authors: C. Francis, D. Pinkas.

Date: May 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4476

This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC). The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specificACPs.

RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues

Authors: T. Chown, S. Venaas, C. Strauf.

Date: May 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4477

A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol(DHCP). The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken.

RFC 4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol

Authors: Y. Nir.

Date: April 2006

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4478

This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2]. With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer. This document describes a mechanism to perform this function.

RFC 4479 A Data Model for Presence

Authors: J. Rosenberg.

Date: July 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4479

This document defines the underlying presence data model used bySession Initiation Protocol (SIP) for Instant Messaging and PresenceLeveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion.

RFC 4480 RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)

Authors: H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg.

Date: July 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4480

The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication.The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence InformationData Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity.
This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity.
These extensions include presence information for persons, services(tuples), and devices.

RFC 4481 Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals

Authors: H. Schulzrinne.

Date: July 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4481

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension(<timed-status&rt; element) that allows a presentity to declare its status for a time interval fully in the future or the past.

RFC 4482 CIPID: Contact Information for the Presence Information Data Format

Authors: H. Schulzrinne.

Date: July 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4482

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. TheContact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons.

RFC 4483 A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages

Authors: E. Burger, Ed..

Date: May 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4483

This document defines an extension to the URL MIME External-BodyAccess-Type to satisfy the content indirection requirements for theSession Initiation Protocol (SIP). These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI.

RFC 4484 Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP)

Authors: J. Peterson, J. Polk, D. Sicker, H. Tschofenig.

Date: August 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4484

This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system.

RFC 4485 Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)

Authors: J. Rosenberg, H. Schulzrinne.

Date: May 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4485

The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across theInternet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions.

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 4487 Mobile IPv6 and Firewalls: Problem Statement

Authors: F. Le, S. Faccin, B. Patil, H. Tschofenig.

Date: May 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4487

This document captures the issues that may arise in the deployment ofIPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such asGeneral Packet Radio Service / Universal Mobile TelecommunicationsSystem (GPRS/UMTS) and CDMA2000 networks.
The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions.

RFC 4488 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription

Authors: O. Levin.

Date: May 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4488

The Session Initiation Protocol (SIP) REFER extension as defined inRFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by theREFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request.

RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses

Authors: J-S. Park, M-K. Shin, H-J. Kim.

Date: April 2006

Formats: txt json html

Updates: RFC 3306

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4489

This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows the use ofInterface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate its unique multicast addresses automatically without conflicts. The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast- prefix-based IPv6 multicast addresses. This memo updates RFC 3306.

RFC 4490 Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)

Authors: S. Leontiev, Ed., G. Chudov, Ed..

Date: May 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4490

This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, andGOST R 34.11-94 with the Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication, and encryption of arbitrary message contents.

RFC 4491 Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile

Authors: S. Leontiev, Ed., D. Shefanovski, Ed..

Date: May 2006

Formats: txt json html

Updates: RFC 3279

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4491

This document supplements RFC 3279. It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509Public Key Infrastructure (PKI).

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 4493 The AES-CMAC Algorithm

Authors: JH. Song, R. Poovendran, J. Lee, T. Iwata.

Date: June 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4493

The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code(CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard(AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community.

RFC 4494 The AES-CMAC-96 Algorithm and Its Use with IPsec

Authors: JH. Song, R. Poovendran, J. Lee.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4494

The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code(CMAC), which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC). This memo specifies the use of CMAC mode on the authentication mechanism of theIPsec Encapsulating Security Payload (ESP) and the AuthenticationHeader (AH) protocols. This new algorithm is named AES-CMAC-96.

RFC 4495 A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow

Authors: J. Polk, S. Dhesikan.

Date: May 2006

Formats: txt json html

Updates: RFC 2205

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4495

This document proposes an extension to the Resource ReservationProtocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations, or other forms ofRSVP tunnels. This specification is an extension of RFC 2205.

RFC 4496 Open Pluggable Edge Services (OPES) SMTP Use Cases

Authors: M. Stecher, A. Barbir.

Date: May 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4496

The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework.This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES.

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 4498 The Managed Object Aggregation MIB

Authors: G. Keeni.

Date: May 2006

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4498

This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the AggregationMIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated ManagedObject instances.

RFC 4501 Domain Name System Uniform Resource Identifiers

Authors: S. Josefsson.

Date: May 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4501

This document defines Uniform Resource Identifiers for Domain NameSystem resources.

RFC 4502 Remote Network Monitoring Management Information Base Version 2

Authors: S. Waldbusser.

Date: May 2006

Formats: txt html json

Obsoletes: RFC 2021

Updates: RFC 3273

Status: DRAFT STANDARD

DOI: 10.17487/RFC 4502

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices.
This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module.

RFC 4503 A Description of the Rabbit Stream Cipher Algorithm

Authors: M. Boesgaard, M. Vesterager, E. Zenner.

Date: May 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4503

This document describes the encryption algorithm Rabbit. It is a stream cipher algorithm with a 128-bit key and 64-bit initialization vector (IV). The method was published in 2003 and has been subject to public security and performance revision. Its high performance makes it particularly suited for the use with Internet protocols where large amounts of data have to be processed.

RFC 4504 SIP Telephony Device Requirements and Configuration

Authors: H. Sinnreich, Ed., S. Lass, C. Stredicke.

Date: May 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4504

This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones andPC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.
We present a glossary of the most common settings and some of the more widely used values for some settings.

RFC 4505 Anonymous Simple Authentication and Security Layer (SASL) Mechanism

Authors: K. Zeilenga.

Date: June 2006

Formats: txt json html

Obsoletes: RFC 2245

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4505

On the Internet, it is common practice to permit anonymous access to various services. Traditionally, this has been done with a plain- text password mechanism using "anonymous" as the user name and using optional trace information, such as an email address, as the password. As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework.

RFC 4506 XDR: External Data Representation Standard

Authors: M. Eisler, Ed..

Date: May 2006

Formats: txt html json

Obsoletes: RFC 1832

Also: STD 0067

Status: INTERNET STANDARD

DOI: 10.17487/RFC 4506

This document describes the External Data Representation Standard(XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832.

RFC 4507 Transport Layer Security (TLS) Session Resumption without Server-Side State

Authors: J. Salowey, H. Zhou, P. Eronen, H. Tschofenig.

Date: May 2006

Formats: txt html json

Obsoleted by: RFC 5077

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4507

This document describes a mechanism that enables the Transport LayerSecurity (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket.

RFC 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 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)

Authors: W. Hardaker.

Date: May 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4509

This document specifies how to use the SHA-256 digest type in DNSDelegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone.

RFC 4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map

Authors: K. Zeilenga, Ed..

Date: June 2006

Formats: txt json html

Obsoletes: RFC 2251, RFC 2252, RFC 2253, RFC 2254, RFC 2255, RFC 2256, RFC 2829, RFC 2830, RFC 3377, RFC 3771

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4510

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document provides a road map of the LDAP Technical Specification.

RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol

Authors: J. Sermersheim, Ed..

Date: June 2006

Formats: txt json html

Obsoletes: RFC 2251, RFC 2830, RFC 3771

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4511

This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol(LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory AccessProtocol (DAP).

RFC 4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models

Authors: K. Zeilenga, Ed..

Date: June 2006

Formats: txt html json

Obsoletes: RFC 2251, RFC 2252, RFC 2256, RFC 3674

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4512

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP.

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 4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names

Authors: K. Zeilenga, Ed..

Date: June 2006

Formats: txt json html

Obsoletes: RFC 2253

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4514

The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol(LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name.

RFC 4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters

Authors: M. Smith, Ed., T. Howes.

Date: June 2006

Formats: txt json html

Obsoletes: RFC 2254

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4515

Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications.

RFC 4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator

Authors: M. Smith, Ed., T. Howes.

Date: June 2006

Formats: txt html json

Obsoletes: RFC 2255

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4516

This document describes a format for a Lightweight Directory AccessProtocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed.

RFC 4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules

Authors: S. Legg, Ed..

Date: June 2006

Formats: txt html json

Obsoletes: RFC 2252, RFC 2256

Updates: RFC 3698

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4517

Each attribute stored in a Lightweight Directory Access Protocol(LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories.

RFC 4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation

Authors: K. Zeilenga.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4518

The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This led to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use inLDAP.

RFC 4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications

Authors: A. Sciberras, Ed..

Date: June 2006

Formats: txt json html

Obsoletes: RFC 2256

Updates: RFC 2247, RFC 2798, RFC 2377

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4519

This document is an integral part of the Lightweight Directory AccessProtocol (LDAP) technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as WhitePages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents.

RFC 4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)

Authors: K. Zeilenga.

Date: June 2006

Formats: txt json html

Obsoletes: RFC 3383

Also: BCP 0064

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4520

This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to the Internet Assigned Numbers Authority(IANA) describing conditions under which new values can be assigned.

RFC 4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions

Authors: K. Zeilenga.

Date: June 2006

Formats: txt json html

Also: BCP 0118

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4521

The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas. This document discusses considerations for designers of LDAP extensions.

RFC 4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option

Authors: S. Legg.

Date: June 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4522

Each attribute stored in a Lightweight Directory Access Protocol(LDAP) directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories.

RFC 4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates

Authors: K. Zeilenga.

Date: June 2006

Formats: txt html json

Obsoletes: RFC 2252, RFC 2256, RFC 2587

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4523

RFC 4524 COSINE LDAP/X.500 Schema

Authors: K. Zeilenga, Ed..

Date: June 2006

Formats: txt json html

Obsoletes: RFC 1274

Updates: RFC 2247, RFC 2798

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4524

This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol (LDAP) from the COSINE andInternet X.500 pilot projects.
This document obsoletes RFC 1274 and updates RFCs 2247 and 2798.

RFC 4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension

Authors: K. Zeilenga.

Date: June 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4525

This document describes an extension to the Lightweight DirectoryAccess Protocol (LDAP) Modify operation to support an increment capability. This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre- read or post-read control extension.

RFC 4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters

Authors: K. Zeilenga.

Date: June 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4526

This document extends the Lightweight Directory Access Protocol(LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters.

RFC 4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls

Authors: K. Zeilenga.

Date: June 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4527

This document specifies an extension to the Lightweight DirectoryAccess Protocol (LDAP) to allow the client to read the target entry of an update operation. The client may request to read the entry before and/or after the modifications are applied. These reads are done as an atomic part of the update operation.

RFC 4528 Lightweight Directory Access Protocol (LDAP) Assertion Control

Authors: K. Zeilenga.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4528

This document defines the Lightweight Directory Access Protocol(LDAP) Assertion Control, which allows a client to specify that a directory operation should only be processed if an assertion applied to the target entry of the operation is true. It can be used to construct "test and set", "test and clear", and other conditional operations.

RFC 4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol

Authors: K. Zeilenga.

Date: June 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4529

The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class.

RFC 4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute

Authors: K. Zeilenga.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4530

This document describes the LDAP/X.500 'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming.

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 4532 Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation

Authors: K. Zeilenga.

Date: June 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4532

This specification provides a mechanism for Lightweight DirectoryAccess Protocol (LDAP) clients to obtain the authorization identity the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP"Who am I?" operation.

RFC 4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation

Authors: K. Zeilenga, J.H. Choi.

Date: June 2006

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4533

This specification describes the Lightweight Directory AccessProtocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the DirectoryInformation Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation.

RFC 4534 Group Security Policy Token v1

Authors: A. Colegrove, H. Harney.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4534

The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. Because the security of a group is composed of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security. This document specifies the structure of such a token.

RFC 4535 GSAKMP: Group Secure Association Key Management Protocol

Authors: H. Harney, U. Meth, A. Colegrove, G. Gross.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4535

This document specifies the Group Secure Association Key ManagementProtocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys.

RFC 4536 The application/smil and application/smil+xml Media Types

Authors: P. Hoschka.

Date: July 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4536

This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL2.0, SMIL 2.1). SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation.

RFC 4537 Kerberos Cryptosystem Negotiation Extension

Authors: L. Zhu, P. Leach, K. Jaganathan.

Date: June 2006

Formats: txt html json

Updates: RFC 4120

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4537

This document specifies an extension to the Kerberos protocol as defined in RFC 4120, in which the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server.

RFC 4538 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)

Authors: J. Rosenberg.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4538

This specification defines the Target-Dialog header field for theSession Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness.

RFC 4539 Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF)

Authors: T. Edwards.

Date: May 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4539

This document serves to register a media type for the Society ofMotion Picture and Television Engineers (SMPTE) Material ExchangeFormat (MXF). MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata.

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 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches

Authors: M. Christensen, K. Kimball, F. Solensky.

Date: May 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4541

This memo describes the recommendations for Internet Group ManagementProtocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes andEthernet-specific encapsulation issues, are also considered.

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 4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH

Authors: D. McGrew, J. Viega.

Date: May 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4543

This memo describes the use of the Advanced Encryption Standard (AES)Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsecEncapsulating Security Payload (ESP) and Authentication Header (AH).GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations.

RFC 4544 Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)

Authors: M. Bakke, M. Krueger, T. McSweeney, J. Muchow.

Date: May 2006

Formats: txt html json

Obsoleted by: RFC 7147

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4544

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing a client using theInternet Small Computer System Interface (iSCSI) protocol (SCSI overTCP).

RFC 4545 Definitions of Managed Objects for IP Storage User Identity Authorization

Authors: M. Bakke, J. Muchow.

Date: May 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4545

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 user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods.

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 4548 Internet Code Point (ICP) Assignments for NSAP Addresses

Authors: E. Gray, J. Rutemiller, G. Swallow.

Date: May 2006

Formats: txt html json

Updates: RFC 1888, RFC 4048

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4548

This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service AccessPoint (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T RecommendationX.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments.

RFC 4549 Synchronization Operations for Disconnected IMAP4 Clients

Authors: A. Melnikov, Ed..

Date: June 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4549

This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.
This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process.
This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients.

RFC 4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile

Authors: S. Maes, A. Melnikov.

Date: June 2006

Formats: txt html json

Obsoleted by: RFC 5550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4550

This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail.This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.
The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409).

RFC 4551 IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization

Authors: A. Melnikov, S. Hole.

Date: June 2006

Formats: txt html json

Obsoleted by: RFC 7162

Updates: RFC 3501

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4551

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.
The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.
This document defines an extension to IMAP (RFC 3501).

RFC 4552 Authentication/Confidentiality for OSPFv3

Authors: M. Gupta, N. Melam.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4552

This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 AuthenticationHeader/Encapsulating Security Payload (AH/ESP) extension header.

RFC 4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)

Authors: A. Vainshtein, Ed., YJ. Stein, Ed..

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4553

This document describes a pseudowire encapsulation for Time DivisionMultiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing.

RFC 4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks

Authors: T. Chown.

Date: June 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4554

Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how suchVLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link.

RFC 4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE)

Authors: P. Eronen.

Date: June 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4555

This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsecSecurity Associations to change. A mobile Virtual Private Network(VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working.

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 4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)

Authors: L. Zhu, K. Jaganathan, N. Williams.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4557

This document defines a mechanism to enable in-band transmission ofOnline Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. These responses are used to verify the validity of the certificates used in Public Key Cryptography forInitial Authentication in Kerberos (PKINIT), which is the KerberosVersion 5 extension that provides for the use of public key cryptography.

RFC 4558 Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement

Authors: Z. Ali, R. Rahman, D. Prairie, D. Papadimitriou.

Date: June 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4558

Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure forResource reSerVation Protocol-Traffic Engineering (RSVP-TE).Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to bothMulti-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes.

RFC 4559 SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows

Authors: K. Jaganathan, L. Zhu, J. Brezak.

Date: June 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4559

This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in MicrosoftWindows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of"negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed.This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple AndProtected Negotiate (SPNEGO) implementation are not provided in this document.

RFC 4560 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations

Authors: J. Quittek, Ed., K. White, Ed..

Date: June 2006

Formats: txt html json

Obsoletes: RFC 2925

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4560

This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host.
Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability.

RFC 4561 Definition of a Record Route Object (RRO) Node-Id Sub-Object

Authors: J.-P. Vasseur, Ed., Z. Ali, S. Sivabalan.

Date: June 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4561

In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic EngineeringLabel Switched Path (TE LSP) on a downstream Label Switching Router(LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an AutonomousSystem (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of anArea Border Router (ABR) or Autonomous System Border Router (ASBR).This document specifies the use of existing Record Route Object (RRO)IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS FastReroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method.

RFC 4562 MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network

Authors: T. Melsen, S. Blake.

Date: June 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4562

This document describes a mechanism to ensure layer-2 separation ofLocal Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.
The mechanism - called "MAC-Forced Forwarding" - implements anAddress Resolution Protocol (ARP) proxy function that prohibitsEthernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts.

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 4564 Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)

Authors: S. Govindan, Ed., H. Cheng, ZH. Yao, WH. Zhou, L. Yang.

Date: July 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4564

This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability amongWireless Local Area Network (WLAN) devices of alternative designs.

RFC 4565 Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols

Authors: D. Loher, D. Nelson, O. Volinsky, B. Sarikaya.

Date: July 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4565

This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26,2005.

RFC 4566 SDP: Session Description Protocol

Authors: M. Handley, V. Jacobson, C. Perkins.

Date: July 2006

Formats: txt json html

Obsoletes: RFC 2327, RFC 3266

Obsoleted by: RFC 8866

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4566

This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.

RFC 4567 Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)

Authors: J. Arkko, F. Lindholm, M. Naslund, K. Norrman, E. Carrara.

Date: July 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4567

This document defines general extensions for Session DescriptionProtocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.
General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia InternetKEYing (MIKEY) key management protocol is also defined.

RFC 4568 Session Description Protocol (SDP) Security Descriptions for Media Streams

Authors: F. Andreasen, M. Baugher, D. Wing.

Date: July 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4568

This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message.

RFC 4569 Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag

Authors: G. Camarillo.

Date: July 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4569

This document registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features.

RFC 4570 Session Description Protocol (SDP) Source Filters

Authors: B. Quinn, R. Finlayson.

Date: July 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4570

This document describes how to adapt the Session Description Protocol(SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations.In particular, an inclusive source-filter can be used to specify aSource-Specific Multicast (SSM) session.

RFC 4571 Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport

Authors: J. Lazzaro.

Date: July 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4571

This memo defines a method for framing Real-time Transport Protocol(RTP) and RTP Control Protocol (RTCP) packets onto connection- oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method.

RFC 4572 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)

Authors: J. Lennox.

Date: July 2006

Formats: txt json html

Obsoleted by: RFC 8122

Updates: RFC 4145

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4572

This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.
This document extends and updates RFC 4145.

RFC 4573 MIME Type Registration for RTP Payload Format for H.224

Authors: R. Even, A. Lochbaum.

Date: July 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4573

In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224.

RFC 4574 The Session Description Protocol (SDP) Label Attribute

Authors: O. Levin, G. Camarillo.

Date: August 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4574

This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context.

RFC 4575 A Session Initiation Protocol (SIP) Event Package for Conference State

Authors: J. Rosenberg, H. Schulzrinne, O. Levin, Ed..

Date: August 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4575

This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components.

RFC 4576 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)

Authors: E. Rosen, P. Psenak, P. Pillay-Esnault.

Date: June 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4576

This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLSIP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge(CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by anyPE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (LinkState Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it.

RFC 4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

Authors: E. Rosen, P. Psenak, P. Pillay-Esnault.

Date: June 2006

Formats: txt json html

Updates: RFC 4364

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4577

Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers(CE routers) are routing peers of provider edge routers (PE routers).The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, andMultiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLSIP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open ShortestPath First (OSPF) protocol.
This document updates RFC 4364.

RFC 4578 Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)

Authors: M. Johnston, S. Venaas, Ed..

Date: November 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4578

We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible FirmwareInterface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client.

RFC 4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents

Authors: A. Johnston, O. Levin.

Date: August 2006

Formats: txt html json

Also: BCP 0119

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4579

This specification defines conferencing call control features for theSession Initiation Protocol (SIP). This document builds on theConferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference- unaware, conference-aware, and focus UAs. The use of UniformResource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined.

RFC 4580 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option

Authors: B. Volz.

Date: June 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4580

This memo defines a new Relay Agent Subscriber-ID option for theDynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure.

RFC 4581 Cryptographically Generated Addresses (CGA) Extension Field Format

Authors: M. Bagnulo, J. Arkko.

Date: October 2006

Formats: txt html json

Updates: RFC 3972

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4581

This document defines a Type-Length-Value format forCryptographically Generated Address (CGA) Extensions. This document updates RFC 3972.

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 4583 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams

Authors: G. Camarillo.

Date: November 2006

Formats: txt json html

Obsoleted by: RFC 8856

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4583

This document specifies how to describe Binary Floor Control Protocol(BFCP) streams in Session Description Protocol (SDP) descriptions.User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers.

RFC 4584 Extension to Sockets API for Mobile IPv6

Authors: S. Chakrabarti, E. Nordmark.

Date: July 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4584

This document describes data structures and API support for MobileIPv6 as an extension to the Advanced Socket API for IPv6.
Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information forMobility Header messages, Home Address destination options, andRouting Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications.

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 4586 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations

Authors: C. Burmeister, R. Hakenberg, A. Miyazaki, J. Ott, N. Sato, S. Fukunaga.

Date: July 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4586

This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time TransportControl Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic.

RFC 4587 RTP Payload Format for H.261 Video Streams

Authors: R. Even.

Date: August 2006

Formats: txt json html

Obsoletes: RFC 2032

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4587

This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP.
The memo also describes the syntax and semantics of the SessionDescription Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.
This specification obsoletes RFC 2032.

RFC 4588 RTP Retransmission Payload Format

Authors: J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg.

Date: July 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4588

RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions.Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-timeTransport Control Protocol (RTCP) feedback as defined in the extendedRTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo.

RFC 4589 Location Types Registry

Authors: H. Schulzrinne, H. Tschofenig.

Date: July 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4589

This document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station.

RFC 4590 RADIUS Extension for Digest Authentication

Authors: B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck.

Date: July 2006

Formats: txt html json

Obsoleted by: RFC 5090

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4590

This document defines an extension to the Remote AuthenticationDial-In User Service (RADIUS) protocol to enable support of DigestAuthentication, for use with HTTP-style protocols like the SessionInitiation Protocol (SIP) and HTTP.

RFC 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 4592 The Role of Wildcards in the Domain Name System

Authors: E. Lewis.

Date: July 2006

Formats: txt json html

Updates: RFC 1034, RFC 2672

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4592

This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034.

RFC 4593 Generic Threats to Routing Protocols

Authors: A. Barbir, S. Murphy, Y. Yang.

Date: October 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4593

Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately.

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 4595 Use of IKEv2 in the Fibre Channel Security Association Management Protocol

Authors: F. Maino, D. Black.

Date: July 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4595

This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the FibreChannel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types. This document specifies theseIKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel.

RFC 4596 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension

Authors: J. Rosenberg, P. Kyzivat.

Date: July 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4596

This document contains guidelines for usage of the Caller PreferencesExtension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841.

RFC 4597 Conferencing Scenarios

Authors: R. Even, N. Ismail.

Date: August 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4597

This document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group.

RFC 4598 Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio

Authors: B. Link.

Date: July 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4598

This document describes a Real-time Transport Protocol (RTP) payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data.E-AC-3 is a high-quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US High-Definition Television (HDTV), DVD, cable and satellite television, and other media. E-AC-3 is an optional audio format in US and world wide digital television and high-definition DVD formats. The RTP payload format as presented in this document includes support for data fragmentation.

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 4602 Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis

Authors: T. Pusateri.

Date: August 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4602

This document provides supporting documentation to advance theProtocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard.

RFC 4603 Additional Values for the NAS-Port-Type Attribute

Authors: G. Zorn, G. Weber, R. Foltak.

Date: July 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4603

This document defines a set of values for the NAS-Port-Type RADIUSAttribute.

RFC 4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast

Authors: H. Holbrook, B. Cain, B. Haberman.

Date: August 2006

Formats: txt html json

Updates: RFC 3376, RFC 3810

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4604

The Internet Group Management Protocol Version 3 (IGMPv3) and theMulticast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively.Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an"SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications.

RFC 4605 Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")

Authors: B. Fenner, H. He, B. Haberman, H. Sandick.

Date: August 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4605

In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol(IGMP) or Multicast Listener Discovery (MLD) membership information.

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 4607 Source-Specific Multicast for IP

Authors: H. Holbrook, B. Cain.

Date: August 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4607

IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to232.255.255.255) range are designated as source-specific multicast(SSM) destination addresses and are reserved for use by source- specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension.

RFC 4608 Source-Specific Protocol Independent Multicast in 232/8

Authors: D. Meyer, R. Rockell, G. Shepherd.

Date: August 2006

Formats: txt html json

Also: BCP 0120

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4608

IP Multicast group addresses in the 232/8 (232.0.0.0 to232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range.

RFC 4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements

Authors: P. Savola, R. Lehtonen, D. Meyer.

Date: October 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4609

This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only ProtocolIndependent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast(ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats.

RFC 4610 Anycast-RP Using Protocol Independent Multicast (PIM)

Authors: D. Farinacci, Y. Cai.

Date: August 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4610

This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only.Other multicast protocols (such as Multicast Source DiscoveryProtocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP.

RFC 4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios

Authors: M. McBride, J. Meylor, D. Meyer.

Date: August 2006

Formats: txt html json

Also: BCP 0121

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4611

This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode(PIM-SM).

RFC 4612 Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration

Authors: P. Jones, H. Tamura.

Date: August 2006

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 4612

This document defines the MIME sub-type audio/t38. The usage of thisMIME type, which is intended for use within Session DescriptionProtocol (SDP), is specified within ITU-T Recommendation T.38.

RFC 4613 Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI)

Authors: P. Frojdh, U. Lindgren, M. Westerlund.

Date: September 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4613

This document serves to register a media type for DownloadableSounds.

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 4615 The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)

Authors: J. Song, R. Poovendran, J. Lee, T. Iwata.

Date: August 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4615

Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced EncryptionStandard (AES). This memo describes such an algorithm, calledAES-CMAC-PRF-128. It supports fixed and variable key sizes.

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 4617 A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project

Authors: J. Kornijenko.

Date: August 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4617

This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor, Olimps LTD, and subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange (RIX) Technologies LTD, and Microlink LTD) for naming information resources published and produced by the Latvian NationalGovernment Integration Project (Latvian abbreviation IVIS).

RFC 4618 Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks

Authors: L. Martini, E. Rosen, G. Heron, A. Malis.

Date: September 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4618

A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over aMultiprotocol Label Switching (MPLS) network without terminating thePPP/HDLC protocol. This enables service providers to offer"emulated" HDLC, or PPP link services over existing MPLS networks.This document specifies the encapsulation of PPP/HDLC Packet DataUnits (PDUs) within a pseudowire.

RFC 4619 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks

Authors: L. Martini, Ed., C. Kawa, Ed., A. Malis, Ed..

Date: September 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4619

A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network(PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network.

RFC 4620 IPv6 Node Information Queries

Authors: M. Crawford, B. Haberman, Ed..

Date: August 2006

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4620

This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging.

RFC 4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol

Authors: T. Kivinen, H. Tschofenig.

Date: August 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4621

The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsecSecurity Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).
This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded.

RFC 4622 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)

Authors: P. Saint-Andre.

Date: July 2006

Formats: txt json html

Obsoleted by: RFC 5122

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4622

This document defines the use of Internationalized ResourceIdentifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via theExtensible Messaging and Presence Protocol (XMPP).

RFC 4623 Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly

Authors: A. Malis, M. Townsley.

Date: August 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4623

This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services.

RFC 4624 Multicast Source Discovery Protocol (MSDP) MIB

Authors: B. Fenner, D. Thaler.

Date: October 2006

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4624

This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC3618) speakers.

RFC 4625 Fibre Channel Routing Information MIB

Authors: C. DeSanti, K. McCloghrie, S. Kode, S. Gai.

Date: September 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4625

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 information related to routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol.

RFC 4626 MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol

Authors: C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai.

Date: September 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4626

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 information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol.

RFC 4627 The application/json Media Type for JavaScript Object Notation (JSON)

Authors: D. Crockford.

Date: July 2006

Formats: txt json html

Obsoleted by: RFC 7159

Status: INFORMATIONAL

DOI: 10.17487/RFC 4627

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

RFC 4628 RTP Payload Format for H.263 Moving RFC 2190 to Historic Status

Authors: R. Even.

Date: January 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4628

The first RFC that describes RTP payload format for ITUTelecommunication Standardization Sector (ITU-T) recommendation H.263 is RFC 2190. This specification discusses why to move RFC 2190 to historic status.

RFC 4629 RTP Payload Format for ITU-T Rec

Authors: H.263 Video. J. Ott, C. Bormann, G. Sullivan, S. Wenger, R. Even, Ed..

Date: January 2007

Formats: txt html json

Obsoletes: RFC 2429

Updates: RFC 3555

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4629

This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.
The document also describes the syntax and semantics of the SessionDescription Protocol (SDP) parameters needed to support the H.263 video codec.
The document obsoletes RFC 2429 and updates the H263-1998 andH263-2000 MIME media type in RFC 3555.

RFC 4630 Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Authors: R. Housley, S. Santesson.

Date: August 2006

Formats: txt html json

Obsoleted by: RFC 5280

Updates: RFC 3280

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4630

This document updates the handling of DirectoryString in the InternetX.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile, which is published in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding.The requirement for exclusive use of UTF8String after December 31,2003 is removed.

RFC 4631 Link Management Protocol (LMP) Management Information Base (MIB)

Authors: M. Dubuc, T. Nadeau, J. Lang, E. McGinnis, A. Farrel.

Date: September 2006

Formats: txt html json

Obsoletes: RFC 4327

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4631

This document provides minor corrections to and obsoletes RFC 4327.
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling the LinkManagement Protocol (LMP).

RFC 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan

Authors: V. Fuller, T. Li.

Date: August 2006

Formats: txt json html

Obsoletes: RFC 1519

Also: BCP 0122

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4632

This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state.This document obsoletes the original Classless Inter-domain Routing(CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described.

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 4634 US Secure Hash Algorithms (SHA and HMAC-SHA)

Authors: D. Eastlake 3rd, T. Hansen.

Date: July 2006

Formats: txt html json

Obsoleted by: RFC 6234

Updates: RFC 3174

Status: INFORMATIONAL

DOI: 10.17487/RFC 4634

The United States of America has adopted a suite of Secure HashAlgorithms (SHAs), including four beyond SHA-1, as part of a FederalInformation Processing Standard (FIPS), specifically SHA-224 (RFC3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS180-2.
Code to perform SHA-based HMACs, with arbitrary bit length text, is also included.

RFC 4635 HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers

Authors: D. Eastlake 3rd.

Date: August 2006

Formats: txt html json

Obsoleted by: RFC 8945

Updates: RFC 2845

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4635

Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code.Currently, identifiers have been specified only for HMAC MD5 (HashedMessage Authentication Code, Message Digest 5) and GSS (GenericSecurity Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA(Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG.

RFC 4636 Foreign Agent Error Extension for Mobile IPv4

Authors: C. Perkins.

Date: October 2006

Formats: txt json html

Updates: RFC 3344

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4636

This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent. The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node.

RFC 4638 Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)

Authors: P. Arberg, D. Kourkouzelis, M. Duckett, T. Anschutz, J. Moisand.

Date: September 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4638

The Point-to-Point Protocol over Ethernet (PPPoE), as described inRFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of1492. This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks.

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 4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6)

Authors: A. Patel, Ed., G. Giaretta, Ed..

Date: September 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4640

A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6(MIPv6) and various potential deployment scenarios for mobile node bootstrapping.

RFC 4641 DNSSEC Operational Practices

Authors: O. Kolkman, R. Gieben.

Date: September 2006

Formats: txt json html

Obsoletes: RFC 2541

Obsoleted by: RFC 6781

Status: INFORMATIONAL

DOI: 10.17487/RFC 4641

This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.
This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification.

RFC 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 4643 Network News Transfer Protocol (NNTP) Extension for Authentication

Authors: J. Vinocur, K. Murchison.

Date: October 2006

Formats: txt html json

Updates: RFC 2980

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4643

This document defines an extension to the Network News TransferProtocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session.
This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates theAUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods.Additionally, this document defines a profile of the SimpleAuthentication and Security Layer (SASL) for NNTP.

RFC 4644 Network News Transfer Protocol (NNTP) Extension for Streaming Feeds

Authors: J. Vinocur, K. Murchison.

Date: October 2006

Formats: txt json html

Updates: RFC 2980

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4644

This memo defines an extension to the Network News Transfer Protocol(NNTP) to provide asynchronous (otherwise known as "streaming") transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency.
This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command.

RFC 4645 Initial Language Subtag Registry

Authors: D. Ewell.

Date: September 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4645

This memo defined the initial contents of the IANA Language SubtagRegistry for use in forming tags for the identification of languages.Since the contents of this memo only served as a starting point for the registry, its actual contents have been removed before publication to avoid confusion.

RFC 4646 Tags for Identifying Languages

Authors: A. Phillips, M. Davis.

Date: September 2006

Formats: txt html json

Obsoletes: RFC 3066

Obsoleted by: RFC 5646

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4646

This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766.

RFC 4647 Matching of Language Tags

Authors: A. Phillips, Ed., M. Davis, Ed..

Date: September 2006

Formats: txt html json

Obsoletes: RFC 3066

Also: BCP 0047

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4647

This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag.Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC3066, which replaced RFC 1766.

RFC 4648 The Base16, Base32, and Base64 Data Encodings

Authors: S. Josefsson.

Date: October 2006

Formats: txt json html

Obsoletes: RFC 3548

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4648

This document describes the commonly used base 64, base 32, and base16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.

RFC 4649 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option

Authors: B. Volz.

Date: August 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4649

This memo defines a new Relay Agent Remote-ID option for the DynamicHost Configuration Protocol for IPv6 (DHCPv6). This option is theDHCPv6 equivalent for the Dynamic Host Configuration Protocol forIPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046.

RFC 4650 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)

Authors: M. Euchner.

Date: September 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4650

This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocolMIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY.

RFC 4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization

Authors: C. Vogt, J. Arkko.

Date: February 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4651

This document describes and evaluates strategies to enhance MobileIPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts)Research Group.

RFC 4652 Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements

Authors: D. Papadimitriou, Ed., L. Ong, J. Sadler, S. Shew, D. Ward.

Date: October 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4652

The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy(SONET/SDH) and Optical Transport Networks (OTNs).
This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically SwitchedOptical Network (ASON) as defined by ITU-T.

RFC 4653 Improving the Robustness of TCP to Non-Congestion Events

Authors: S. Bhandarkar, A. L. N. Reddy, M. Allman, E. Blanton.

Date: August 2006

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4653

This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments.However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications.

RFC 4654 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification

Authors: J. Widmer, M. Handley.

Date: August 2006

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4654

This document specifies TCP-Friendly Multicast Congestion Control(TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions.TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media.

RFC 4655 A Path Computation Element (PCE)-Based Architecture

Authors: A. Farrel, J.-P. Vasseur, J. Ash.

Date: August 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4655

Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching(MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.
This document specifies the architecture for a Path ComputationElement (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed.

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 4657 Path Computation Element (PCE) Communication Protocol Generic Requirements

Authors: J. Ash, Ed., J.L. Le Roux, Ed..

Date: September 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4657

The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients(PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs andPCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol.

RFC 4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN

Authors: J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur.

Date: September 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4659

This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6.In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines anIPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".
This document defines support of the IPv6 VPN service over both anIPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic RoutingEncapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document.

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 4661 An Extensible Markup Language (XML)-Based Format for Event Notification Filtering

Authors: H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena.

Date: September 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4661

The SIP event notification framework describes the usage of theSession Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document.

RFC 4662 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists

Authors: A. B. Roach, B. Campbell, J. Rosenberg.

Date: August 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4662

This document presents an extension to the Session InitiationProtocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes.

RFC 4663 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG

Authors: D. Harrington.

Date: September 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4663

This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage.

RFC 4664 Framework for Layer 2 Virtual Private Networks (L2VPNs)

Authors: L. Andersson, Ed., E. Rosen, Ed..

Date: September 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4664

This document provides a framework for Layer 2 Provider ProvisionedVirtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperableL2VPNs.

RFC 4665 Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks

Authors: W. Augustyn, Ed., Y. Serbest, Ed..

Date: September 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4665

This document provides requirements for Layer 2 Provider-ProvisionedVirtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs, referred to as Virtual Private WireService (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from both a customer as well as a service provider perspectives.

RFC 4666 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)

Authors: K. Morneault, Ed., J. Pastor-Balbas, Ed..

Date: September 2006

Formats: txt html json

Obsoletes: RFC 3332

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4666

This memo defines a protocol for supporting the transport of any SS7MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a MediaGateway Controller (MGC) or IP-resident Database, or between two IP- based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 MessageTransfer Part (MTP) to provide transport. This document obsoletesRFC 3332.

RFC 4667 Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)

Authors: W. Luo.

Date: September 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4667

The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types ofL2VPNs in a unified fashion.

RFC 4668 RADIUS Authentication Client MIB for IPv6

Authors: D. Nelson.

Date: August 2006

Formats: txt json html

Obsoletes: RFC 2618

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4668

This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients.
This memo obsoletes RFC 2618 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2618 are carried forward into this document. The memo also addsUNITS and REFERENCE clauses to selected objects.

RFC 4669 RADIUS Authentication Server MIB for IPv6

Authors: D. Nelson.

Date: August 2006

Formats: txt json html

Obsoletes: RFC 2619

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4669

This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers.
This memo obsoletes RFC 2619 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2619 are carried forward into this document. This memo also addsUNITS and REFERENCE clauses to selected objects.

RFC 4670 RADIUS Accounting Client MIB for IPv6

Authors: D. Nelson.

Date: August 2006

Formats: txt json html

Obsoletes: RFC 2620

Status: INFORMATIONAL

DOI: 10.17487/RFC 4670

This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions,IP-based management stations can manage RADIUS accounting clients.
This memo obsoletes RFC 2620 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2620 are carried forward into this document. This memo also addsUNITS and REFERENCE clauses to selected objects.

RFC 4671 RADIUS Accounting Server MIB for IPv6

Authors: D. Nelson.

Date: August 2006

Formats: txt json html

Obsoletes: RFC 2621

Status: INFORMATIONAL

DOI: 10.17487/RFC 4671

This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions,IP-based management stations can manage RADIUS accounting servers.
This memo obsoletes RFC 2621 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2621 are carried forward into this document. This memo also addsUNITS and REFERENCE clauses to selected objects.

RFC 4672 RADIUS Dynamic Authorization Client MIB

Authors: S. De Cnodder, N. Jonnala, M. Chiba.

Date: September 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4672

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 the Remote Authentication Dial-In UserService (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576.

RFC 4673 RADIUS Dynamic Authorization Server MIB

Authors: S. De Cnodder, N. Jonnala, M. Chiba.

Date: September 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4673

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 the Remote Authentication Dial-In UserService (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576.

RFC 4674 Requirements for Path Computation Element (PCE) Discovery

Authors: J.L. Le Roux, Ed..

Date: October 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4674

This document presents a set of requirements for a Path ComputationElement (PCE) discovery mechanism that would allow a Path ComputationClient (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements.

RFC 4675 RADIUS Attributes for Virtual LAN and Priority Support

Authors: P. Congdon, M. Sanchez, B. Aboba.

Date: September 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4675

This document proposes additional Remote Authentication Dial-In UserService (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks. These attributes are usable within either RADIUS orDiameter.

RFC 4676 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information

Authors: H. Schulzrinne.

Date: October 2006

Formats: txt html json

Obsoleted by: RFC 4776

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4676

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or theDHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages.

RFC 4677 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force

Authors: P. Hoffman, S. Harris.

Date: September 2006

Formats: txt html json

Obsoletes: RFC 3160

Obsoleted by: RFC 6722

Status: INFORMATIONAL

DOI: 10.17487/RFC 4677

This document describes the inner workings of IETF meetings andWorking Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview.

RFC 4678 Server/Application State Protocol v1

Authors: A. Bivens.

Date: September 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4678

Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. TheServer/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members.

RFC 4679 DSL Forum Vendor-Specific RADIUS Attributes

Authors: V. Mammoliti, G. Zorn, P. Arberg, R. Rennison.

Date: September 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4679

This document describes the set of Remote Authentication Dial-In UserService Vendor-Specific Attributes (RADIUS VSAs) defined by the DSLForum.
These attributes are designed to transport Digital Subscriber Line(DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products.

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 4683 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)

Authors: J. Park, J. Lee, H. Lee, S. Park, T. Polk.

Date: October 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4683

This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.
The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier.

RFC 4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)

Authors: P. Marques, R. Bonica, L. Fang, L. Martini, R. Raszuk, K. Patel, J. Guichard.

Date: November 2006

Formats: txt json html

Updates: RFC 4364

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4684

This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information.This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN)Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364.

RFC 4685 Atom Threading Extensions

Authors: J. Snell.

Date: September 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4685

This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format.

RFC 4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)

Authors: J. Fenton.

Date: September 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4686

This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks.

RFC 4687 Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks

Authors: S. Yasukawa, A. Farrel, D. King, T. Nadeau.

Date: September 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4687

Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.
For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.
This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs.

RFC 4688 A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D

Authors: S. Rushing.

Date: October 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4688

This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by Aerospace and DefenceIndustries Association of Europe (ASD) Specification 1000D.

RFC 4689 Terminology for Benchmarking Network-layer Traffic Control Mechanisms

Authors: S. Poretsky, J. Perser, S. Erramilli, S. Khurana.

Date: October 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4689

This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms.Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number.

RFC 4690 Review and Recommendations for Internationalized Domain Names (IDNs)

Authors: J. Klensin, P. Faltstrom, C. Karp, IAB.

Date: September 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4690

This note describes issues raised by the deployment and use ofInternationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for theInternationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed.

RFC 4691 Guidelines for Acting as an IETF Liaison to Another Organization

Authors: L. Andersson, Ed..

Date: October 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4691

Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization(SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052. This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them.

RFC 4692 Considerations on the IPv6 Host Density Metric

Authors: G. Huston.

Date: October 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4692

This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches.

RFC 4693 IETF Operational Notes

Authors: H. Alvestrand.

Date: October 2006

Formats: txt html json

Obsoleted by: RFC 6393

Status: HISTORIC

DOI: 10.17487/RFC 4693

This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.
It proposes to establish this series as an RFC 3933 process experiment.

RFC 4694 Number Portability Parameters for the "tel" URI

Authors: J. Yu.

Date: October 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4694

This document defines five parameters in the "tel" Uniform ResourceIdentifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed.

RFC 4695 RTP Payload Format for MIDI

Authors: J. Lazzaro, J. Wawrzynek.

Date: November 2006

Formats: txt json html

Obsoleted by: RFC 6295

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4695

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including theMIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable SoundsLevel 2, and Structured Audio.

RFC 4696 An Implementation Guide for RTP MIDI

Authors: J. Lazzaro, J. Wawrzynek.

Date: November 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4696

This memo offers non-normative implementation guidance for the Real- time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room.Underlying the performances are RTP MIDI sessions over unicast UDP.Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail.Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications.

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 4698 IRIS: An Address Registry (areg) Type for the Internet Registry Information Service

Authors: E. Gunduz, A. Newton, S. Kerr.

Date: October 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4698

This document describes an IRIS registry schema for IP address andAutonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used byInternet Protocol address registries.

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 4702 The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option

Authors: M. Stapp, B. Volz, Y. Rekhter.

Date: October 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4702

This document describes a Dynamic Host Configuration Protocol forIPv4 (DHCPv4) option that can be used to exchange information about aDHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment.

RFC 4703 Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients

Authors: M. Stapp, B. Volz.

Date: October 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4703

The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names(FQDNs) require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts.

RFC 4704 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option

Authors: B. Volz.

Date: October 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4704

This document specifies a new Dynamic Host Configuration Protocol forIPv6 (DHCPv6) option that can be used to exchange information about aDHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments.

RFC 4705 GigaBeam High-Speed Radio Link Encryption

Authors: R. Housley, A. Corry.

Date: October 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4705

This document describes the encryption and key management used byGigaBeam as part of the WiFiber(tm) family of radio link products.The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities.

RFC 4706 Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)

Authors: M. Morgenstern, M. Dodge, S. Baillie, U. Bonollo.

Date: November 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4706

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the"Asymmetric Digital Subscriber Line" family of interface types: ADSL,ADSL2, ADSL2+, and their variants.

RFC 4707 Netnews Administration System (NAS)

Authors: P. Grau, V. Heinau, H. Schlichting, R. Schuettler.

Date: October 2006

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4707

The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol.
The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually.News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user.
NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible.Furthermore, NAS is able to reflect the somewhat chaotic structure ofUsenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS- compliant software.

RFC 4708 CellML Media Type

Authors: A. Miller.

Date: October 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4708

This document standardises a new media type -- application/cellml+xml-- for use in exchanging mathematical models represented in a CellMLUmbrella 1.0 compliant markup language.

RFC 4709 Mounting Web Distributed Authoring and Versioning (WebDAV) Servers

Authors: J. Reschke.

Date: October 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4709

In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of aWeb Distinguished Authoring and Versioning (WebDAV) server. For example, it is frequently desirable to be able to click on a link and have this link open a window that can handle drag-and-drop interaction with the resources of a WebDAV server.
This document specifies a mechanism and a document format that enables WebDAV servers to send "mounting" information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type.

RFC 4710 Real-time Application Quality-of-Service Monitoring (RAQMON) Framework

Authors: A. Siddiqui, D. Romascanu, E. Golovinsky.

Date: October 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4710

There is a need to monitor end-devices such as IP phones, pagers,Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring(RMON) family of specifications to allow real-time quality-of-service(QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications.

RFC 4711 Real-time Application Quality-of-Service Monitoring (RAQMON) MIB

Authors: A. Siddiqui, D. Romascanu, E. Golovinsky.

Date: October 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4711

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.The document proposes an extension to the Remote Monitoring MIB, RFC2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring.

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 4713 Registration and Administration Recommendations for Chinese Domain Names

Authors: X. Lee, W. Mao, E. Chen, N. Hsu, J. Klensin.

Date: October 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4713

Many Chinese characters in common use have variants, which makes most of the Chinese Domain Names (CDNs) have at least two different forms.The equivalence between Simplified Chinese (SC) and TraditionalChinese (TC) characters is very important for CDN registration. This memo builds on the basic concepts, general guidelines, and framework of RFC 3743 to specify proposed registration and administration procedures for Chinese domain names. The document provides the information needed for understanding and using the tables defined in the IANA table registrations for Simplified and Traditional Chinese.

RFC 4714 Requirements for IETF Technical Publication Service

Authors: A. Mankin, S. Hayes.

Date: October 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4714

The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation.Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process.

RFC 4715 The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI

Authors: M. Munakata, S. Schubert, T. Ohba.

Date: November 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4715

Without a tel URI parameter to carry an encoding type of IntegratedServices Digital Network (ISDN) subaddress, interworking between ISDNUser Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases. To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress.

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 4717 Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks

Authors: L. Martini, J. Jayakumar, M. Bocci, N. El-Aawar, J. Brayley, G. Koleyni.

Date: December 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4717

An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carryATM cells over an MPLS network. This enables service providers to offer "emulated" ATM services over existing MPLS networks. This document specifies methods for the encapsulation of ATM cells within a pseudowire. It also specifies the procedures for using a PW to provide an ATM service.

RFC 4718 IKEv2 Clarifications and Implementation Guidelines

Authors: P. Eronen, P. Hoffman.

Date: October 2006

Formats: txt json html

Obsoleted by: RFC 5996

Status: INFORMATIONAL

DOI: 10.17487/RFC 4718

This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations.

RFC 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 4720 Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention

Authors: A. Malis, D. Allan, N. Del Regno.

Date: November 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4720

This document defines a mechanism for preserving Frame Check Sequence(FCS) through Ethernet, Frame Relay, High-Level Data Link Control(HDLC), and PPP pseudowires.

RFC 4721 Mobile IPv4 Challenge/Response Extensions (Revised)

Authors: C. Perkins, P. Calhoun, J. Bharatia.

Date: January 2007

Formats: txt json html

Obsoletes: RFC 3012

Updates: RFC 3344

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4721

Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent.Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays and does not allow for the use of existing techniques (such as ChallengeHandshake Authentication Protocol (CHAP)) for authenticating portable computer devices.
In this specification, we define extensions for the Mobile IP AgentAdvertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.
Furthermore, this document updates RFC 3344 by including a new authentication extension called the Mobile-Authentication,Authorization, and Accounting (AAA) Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. This document obsoletes RFC 3012.

RFC 4722 Media Server Control Markup Language (MSCML) and Protocol

Authors: J. Van Dyke, E. Burger, Ed., A. Spitzer.

Date: November 2006

Formats: txt html json

Obsoleted by: RFC 5022

Status: INFORMATIONAL

DOI: 10.17487/RFC 4722

Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework.

RFC 4723 Registration of Media Type audio/mobile-xmf

Authors: T. Kosonen, T. White.

Date: December 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4723

The MIDI Manufacturers Association (MMA) and the Association ofMusical Electronics Industry (AMEI) have produced the Mobile XMF standard, which was developed particularly for mobile MIDI applications. Mobile XMF is a very compact media type providing high-quality synthetic audio content for music downloading and messaging applications that require MIME registration. This document registers the media type audio/mobile-xmf.

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 4725 ENUM Validation Architecture

Authors: A. Mayrhofer, B. Hoeneisen.

Date: November 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4725

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of anENUM domain name is identical to the Assignee of the correspondingE.164 number is commonly called "validation". This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure.

RFC 4726 A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering

Authors: A. Farrel, J.-P. Vasseur, A. Ayyangar.

Date: November 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4726

This document provides a framework for establishing and controllingMultiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.
For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and AutonomousSystems (ASes).

RFC 4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers

Authors: B. Fenner.

Date: November 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4727

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents.

RFC 4728 The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4

Authors: D. Johnson, Y. Hu, D. Maltz.

Date: February 2007

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4728

The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of "Route Discovery" and"Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network.All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness.Other advantages of the DSR protocol include easily guaranteed loop- free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets.

RFC 4729 A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum

Authors: M. Abel.

Date: November 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4729

This document describes the Namespace Identifier (NID) for UniformResource Name (URN) resources published by the Near FieldCommunication (NFC) Forum. The NFC Forum defines and manages resources that utilize this URN identification model. Management activities for these and other resource types are provided by the NFCForum Technical Committee.

RFC 4730 A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)

Authors: E. Burger, M. Dolly.

Date: November 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4730

This document describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and usesExtensible Markup Language (XML) documents referred to as Key PressMarkup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in theSession Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses(triggers).

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 4734 Definition of Events for Modem, Fax, and Text Telephony Signals

Authors: H. Schulzrinne, T. Taylor.

Date: December 2006

Formats: txt json html

Obsoletes: RFC 2833

Updates: RFC 4733

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4734

This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833.

RFC 4735 Example Media Types for Use in Documentation

Authors: T. Taylor.

Date: October 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4735

This document is registration for the 'example' media type and'example' subtypes within the standards tree. The 'example/*' and'*/example' media types are defined for documentation purposes only.

RFC 4736 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)

Authors: JP. Vasseur, Ed., Y. Ikejiri, R. Zhang.

Date: November 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4736

This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching)Traffic Engineering (TE) Label Switched Paths (LSPs) signaled withResource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end LabelSwitching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists(compared to the current path) or that the TE LSP must be reoptimized(because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (InteriorGateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path.

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 4738 MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)

Authors: D. Ignjatic, L. Dondeti, F. Audet, P. Lin.

Date: November 2006

Formats: txt json html

Updates: RFC 3830

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4738

The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution solution that address multimedia scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP) sessions) using pre-shared keys, public keys, and optionally aDiffie-Hellman key exchange. In the public-key mode, the Initiator encrypts a random key with the Responder's public key and sends it to the Responder. In many communication scenarios, the Initiator may not know the Responder's public key, or in some cases the Responder'sID (e.g., call forwarding) in advance. We propose a new MIKEY mode that works well in such scenarios. This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members). This document updates RFC 3830 with the RSA-R mode.

RFC 4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol

Authors: P. Eronen, J. Korhonen.

Date: November 2006

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4739

The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and ExtensibleAuthentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by anEAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider.

RFC 4740 Diameter Session Initiation Protocol (SIP) Application

Authors: M. Garcia-Martin, Ed., M. Belinchon, M. Pallares-Lopez, C. Canales-Valenzuela, K. Tammi.

Date: November 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4740

This document specifies the Diameter Session Initiation Protocol(SIP) application. This is a Diameter application that allows aDiameter client to request authentication and authorization information. This application is designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server.

RFC 4741 NETCONF Configuration Protocol

Authors: R. Enns, Ed..

Date: December 2006

Formats: txt html json

Obsoleted by: RFC 6241

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4741

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible MarkupLanguage (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer.

RFC 4742 Using the NETCONF Configuration Protocol over Secure SHell (SSH)

Authors: M. Wasserman, T. Goddard.

Date: December 2006

Formats: txt json html

Obsoleted by: RFC 6242

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4742

This document describes a method for invoking and running the NetworkConfiguration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem.

RFC 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 4745 Common Policy: A Document Format for Expressing Privacy Preferences

Authors: H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, J. Rosenberg.

Date: February 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4745

This document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains.

RFC 4746 Extensible Authentication Protocol (EAP) Password Authenticated Exchange

Authors: T. Clancy, W. Arbaugh.

Date: November 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4746

This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange). This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange.

RFC 4747 The Virtual Fabrics MIB

Authors: S. Kipp, G. Ramkumar, K. McCloghrie.

Date: November 2006

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4747

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 information related to the Fibre Channel network's Virtual Fabrics function.

RFC 4748 RFC 3978 Update to Recognize the IETF Trust

Authors: S. Bradner, Ed..

Date: October 2006

Formats: txt html json

Obsoleted by: RFC 5378

Updates: RFC 3978

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4748

This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of allIETF-related intellectual property rights.
This document does not constrain how the IETF Trust exercises those rights.

RFC 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 4750 OSPF Version 2 Management Information Base

Authors: D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., R. Coltun, F. Baker.

Date: December 2006

Formats: txt html json

Obsoletes: RFC 1850

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4750

RFC 4752 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism

Authors: A. Melnikov, Ed..

Date: November 2006

Formats: txt json html

Obsoletes: RFC 2222

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4752

The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols.This document describes the method for using the Generic SecurityService Application Program Interface (GSS-API) Kerberos V5 in theSASL.
This document replaces Section 7.2 of RFC 2222, the definition of the"GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222.

RFC 4753 ECP Groups For IKE and IKEv2

Authors: D. Fu, J. Solinas.

Date: January 2007

Formats: txt json html

Obsoleted by: RFC 5903

Status: INFORMATIONAL

DOI: 10.17487/RFC 4753

This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups.Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to alignIKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups.

RFC 4754 IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)

Authors: D. Fu, J. Solinas.

Date: January 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4754

This document describes how the Elliptic Curve Digital SignatureAlgorithm (ECDSA) may be used as the authentication method within theInternet Key Exchange (IKE) and Internet Key Exchange version 2(IKEv2) protocols. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods.This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation.

RFC 4755 IP over InfiniBand: Connected Mode

Authors: V. Kashyap.

Date: December 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4755

This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand.

RFC 4756 Forward Error Correction Grouping Semantics in Session Description Protocol

Authors: A. Li.

Date: November 2006

Formats: txt json html

Obsoleted by: RFC 5956

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4756

This document defines the semantics that allow for grouping ofForward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in theSession Description Protocol" (RFC 3388) to group together "m" lines in the same session.

RFC 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 4758 Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1

Authors: M. Nystroem.

Date: November 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4758

This document constitutes Revision 1 of Cryptographic Token KeyInitialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories'One-Time Password Specifications (OTPS) series. The body of this document, except for the intellectual property considerations section, is taken from the CT-KIP Version 1.0 document, but comments received during the IETF review are reflected; hence, the status of a revised version. As no "bits-on-the-wire" have changed, the protocol specified herein is compatible with CT-KIP Version 1.0.
CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself.

RFC 4759 The ENUM Dip Indicator Parameter for the "tel" URI

Authors: R. Stastny, R. Shockey, L. Conroy.

Date: December 2006

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4759

This document defines a new parameter "enumdi" for the "tel" UniformResource Identifier (URI) to support the handling of ENUM queries inVoice over Internet Protocol (VoIP) network elements. A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if aVoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number.

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 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling

Authors: M. Lasserre, Ed., V. Kompella, Ed..

Date: January 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4762

This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS).A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.
This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extendingRFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448.

RFC 4763 Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)

Authors: M. Vanderveen, H. Soliman.

Date: November 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4763

This document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment(SAKE). This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748.The specification has passed Designated Expert review for this IANA assignment.

RFC 4764 The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method

Authors: F. Bersani, H. Tschofenig.

Date: January 2007

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4764

This document specifies EAP-PSK, an Extensible AuthenticationProtocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11.

RFC 4765 The Intrusion Detection Message Exchange Format (IDMEF)

Authors: H. Debar, D. Curry, B. Feinstein.

Date: March 2007

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4765

The purpose of the Intrusion Detection Message Exchange Format(IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.
This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in theExtensible Markup Language (XML) is presented, an XML Document TypeDefinition is developed, and examples are provided.

RFC 4766 Intrusion Detection Message Exchange Requirements

Authors: M. Wood, M. Erlinger.

Date: March 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4766

The purpose of the Intrusion Detection Exchange Format Working Group(IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements.

RFC 4767 The Intrusion Detection Exchange Protocol (IDXP)

Authors: B. Feinstein, G. Matthews.

Date: March 2007

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4767

This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described inRFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange FormatWorking Group (IDWG) of the IETF.

RFC 4768 Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming

Authors: S. Hartman.

Date: December 2006

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4768

The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions.Advances in security mechanisms and the way implementers wish to useGSS-API require this model to be extended for the next version ofGSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion.

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 4770 vCard Extensions for Instant Messaging (IM)

Authors: C. Jennings, J. Reschke, Ed..

Date: January 2007

Formats: txt html json

Obsoleted by: RFC 6350

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4770

This document describes an extension to vCard to support InstantMessaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard.

RFC 4771 Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)

Authors: V. Lehtovirta, M. Naslund, K. Norrman.

Date: January 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4771

This document defines an integrity transform for Secure Real-timeTransport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization.

RFC 4772 Security Implications of Using the Data Encryption Standard (DES)

Authors: S. Kelly.

Date: December 2006

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4772

The Data Encryption Standard (DES) is susceptible to brute-force attacks, which are well within the reach of a modestly financed adversary. As a result, DES has been deprecated, and replaced by theAdvanced Encryption Standard (AES). Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to support it in new applications. While this is not always inappropriate, it frequently is. This note discusses DES security implications in detail, so that designers and implementers have all the information they need to make judicious decisions regarding its use.

RFC 4773 Administration of the IANA Special Purpose IPv6 Address Block

Authors: G. Huston.

Date: December 2006

Formats: txt json html

Obsoleted by: RFC 6890

Status: INFORMATIONAL

DOI: 10.17487/RFC 4773

This is a direction to IANA concerning the management of the IANASpecial Purpose IPv6 address assignment registry.

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 4775 Procedures for Protocol Extensions and Variations

Authors: S. Bradner, B. Carpenter, Ed., T. Narten.

Date: December 2006

Formats: txt html json

Also: BCP 0125

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4775

This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.
This document is directed principally at other Standards DevelopmentOrganizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes.

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 4777 IBM's iSeries Telnet Enhancements

Authors: T. Murphy Jr., P. Rieth, J. Stevens.

Date: November 2006

Formats: txt json html

Obsoletes: RFC 2877

Status: INFORMATIONAL

DOI: 10.17487/RFC 4777

This document describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allowsTelnet clients to request a Telnet terminal or printer session using specific session attributes related to device names, encryption, language support, auto-sign-on, response codes, session association, etc.
These support functions are implemented primarily using the TelnetEnvironment option negotiation RFC 1572 to define new USERVAR variables that will be recognized by iSeries Telnet server.

RFC 4778 Operational Security Current Practices in Internet Service Provider Environments

Authors: M. Kaeo.

Date: January 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4778

This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments.

RFC 4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks

Authors: S. Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet.

Date: January 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4779

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP)Broadband (BB) networks in coexistence with deployed IPv4 services.Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6.

RFC 4780 Management Information Base for the Session Initiation Protocol (SIP)

Authors: K. Lingle, J-F. Mule, J. Maeng, D. Walker.

Date: April 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4780

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include UserAgents, and Proxy, Redirect and Registrar servers.

RFC 4781 Graceful Restart Mechanism for BGP with MPLS

Authors: Y. Rekhter, R. Aggarwal.

Date: January 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4781

A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism forBGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's(LSR's) control plane restart, and specifically by the restart of itsBGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.
The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network LayerReachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried inBGP (e.g., IPv4, IPv6, etc.).

RFC 4782 Quick-Start for TCP and IP

Authors: S. Floyd, M. Allman, A. Jain, P. Sarolahti.

Date: January 2007

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4782

This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.
This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers,IP tunnels, MPLS paths, and the like that do not support Quick-Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where theQuick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.

RFC 4783 GMPLS - Communication of Alarm Information

Authors: L. Berger, Ed..

Date: December 2006

Formats: txt json html

Updates: RFC 3473

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4783

This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object.
This document updates RFC 3473, "Generalized Multi-Protocol LabelSwitching (GMPLS) Signaling Resource ReserVation Protocol-TrafficEngineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473.

RFC 4784 Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks

Authors: C. Carroll, F. Quick.

Date: June 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4784

The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update(DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUSAuthentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as aMobile IP Foreign Agent (FA). cdma2000(R) is a registered trademark of the TelecommunicationsIndustry Association (TIA).

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 4786 Operation of Anycast Services

Authors: J. Abley, K. Lindqvist.

Date: December 2006

Formats: txt json html

Also: BCP 0126

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4786

As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.
Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast.

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 4789 Simple Network Management Protocol (SNMP) over IEEE 802 Networks

Authors: J. Schoenwaelder, T. Jeffree.

Date: November 2006

Formats: txt html json

Obsoletes: RFC 1089

Updates: RFC 3417

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4789

This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks.
This document obsoletes RFC 1089.

RFC 4790 Internet Application Protocol Collation Registry

Authors: C. Newman, M. Duerst, A. Gulbrandsen.

Date: March 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4790

Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the InternetEngineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future.

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 4792 Encoding Instructions for the Generic String Encoding Rules (GSER)

Authors: S. Legg.

Date: January 2007

Formats: txt json html

Updates: RFC 3641

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4792

Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules(GSER) and, in particular, defines an encoding instruction to provide a machine-processable representation for the declaration of a GSERChoiceOfStrings type.

RFC 4793 The EAP Protected One-Time Password Protocol (EAP-POTP)

Authors: M. Nystroem.

Date: February 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4793

This document describes a general Extensible Authentication Protocol(EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet KeyExchange Protocol Version 2 (IKEv2).

RFC 4794 RFC 1264 Is Obsolete

Authors: B. Fenner.

Date: December 2006

Formats: txt html json

Obsoletes: RFC 1264

Status: INFORMATIONAL

DOI: 10.17487/RFC 4794

RFC 1264 was written during what was effectively a completely different time in the life of the Internet. It prescribed rules to protect the Internet against new routing protocols that may have various undesirable properties. In today's Internet, there are so many other pressures against deploying unreasonable protocols that we believe that existing controls suffice, and the RFC 1264 rules just get in the way.

RFC 4795 Link-local Multicast Name Resolution (LLMNR)

Authors: B. Aboba, D. Thaler, L. Esibov.

Date: January 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4795

The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and futureDNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute forDNS.

RFC 4796 The Session Description Protocol (SDP) Content Attribute

Authors: J. Hautakorpi, G. Camarillo.

Date: February 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4796

This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently(e.g., show it on a big or small screen) based on its content.

RFC 4797 Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks

Authors: Y. Rekhter, R. Bonica, E. Rosen.

Date: January 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4797

This document describes an implementation strategy for BGP/MPLS IPVirtual Private Networks (VPNs) in which the outermost MPLS label(i.e., the tunnel label) is replaced with either an IP header or anIP header with Generic Routing Encapsulation (GRE).
The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not.

RFC 4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)

Authors: J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur.

Date: February 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4798

This document explains how to interconnect IPv6 islands over aMultiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are DualStack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using theMultiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the6PE router so that dynamically established IPv4-signaled MPLS LabelSwitched Paths (LSPs) can be used without explicit tunnel configuration.

RFC 4801 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management

Authors: T. Nadeau, Ed., A. Farrel, Ed..

Date: February 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4801

This document defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly usedGeneralized Multiprotocol Label Switching (GMPLS) management information. The intent is that these textual conventions will be imported and used in GMPLS-related MIB modules that would otherwise define their own representations.

RFC 4802 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base

Authors: T. Nadeau, Ed., A. Farrel, Ed..

Date: February 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4802

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 GeneralizedMultiprotocol Label Switching (GMPLS)-based traffic engineering.

RFC 4803 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base

Authors: T. Nadeau, Ed., A. Farrel, Ed..

Date: February 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4803

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 to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) LabelSwitching Router (LSR).

RFC 4804 Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels

Authors: F. Le Faucheur, Ed..

Date: February 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4804

RFC 3175 specifies aggregation of Resource ReSerVation Protocol(RSVP) end-to-end reservations over aggregate RSVP reservations.This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-awareMPLS Traffic Engineering (DS-TE) tunnels. This approach is based onRFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels.

RFC 4805 Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types

Authors: O. Nicklass, Ed..

Date: March 2007

Formats: txt json html

Obsoletes: RFC 3895

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4805

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS1, J1, E1,DS2, and E2 interfaces. This document is a companion to the documents that define managed objects for the DS0, DS3/E3, andSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Interface Types.
This document obsoletes RFC 3895.

RFC 4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2

Authors: M. Myers, H. Tschofenig.

Date: February 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4806

While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-bandCertificate Revocation Lists (CRL) is problematic due to unboundedCRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSPContent" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.
When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies whenOCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network.

RFC 4807 IPsec Security Policy Database Configuration MIB

Authors: M. Baer, R. Charlet, W. Hardaker, R. Story, C. Wang.

Date: March 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4807

This document defines a Structure of Management Information Version 2(SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol.The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions.

RFC 4808 Key Change Strategies for TCP-MD5

Authors: S. Bellovin.

Date: March 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4808

The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit(mostly) unsynchronized key changes.

RFC 4809 Requirements for an IPsec Certificate Management Profile

Authors: C. Bonatti, Ed., S. Turner, Ed., G. Lebovitz, Ed..

Date: February 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4809

This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) VirtualPrivate Network (VPN) Systems using Internet Key Exchange (IKE)(versions 1 and 2) and Public Key Infrastructure (PKI) Systems.These requirements are designed to meet the needs of enterprise-scaleIPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements.

RFC 4810 Long-Term Archive Service Requirements

Authors: C. Wallace, U. Pordesch, R. Brandner.

Date: March 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4810

There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services.

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 4812 OSPF Restart Signaling

Authors: L. Nguyen, A. Roy, A. Zinin.

Date: March 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4812

OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via theHello subprotocol. Hello OSPF packets are also used to ensure two- way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends aHello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions.
This memo describes a vendor-specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before GracefulOSPF 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 4813 OSPF Link-Local Signaling

Authors: B. Friedman, L. Nguyen, A. Roy, D. Yeung, A. Zinin.

Date: March 2007

Formats: txt html json

Obsoleted by: RFC 5613

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4813

OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link.

RFC 4814 Hash and Stuffing: Overlooked Factors in Network Device Benchmarking

Authors: D. Newman, T. Player.

Date: March 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4814

Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results.First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic.

RFC 4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095

Authors: L-E. Jonsson, K. Sandlund, G. Pelletier, P. Kremer.

Date: February 2007

Formats: txt json html

Updates: RFC 3095, RFC 3241, RFC 3843, RFC 4019, RFC 4362

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4815

RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol),RTP (Real-Time Transport Protocol), and ESP (Encapsulating SecurityPayload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) andRFC 4109 (ROHC UDP-Lite profiles) are also provided.

RFC 4816 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service

Authors: A. Malis, L. Martini, J. Brayley, T. Walsh.

Date: February 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4816

The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for Pseudowire EmulationEdge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell encapsulation.

RFC 4817 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3

Authors: M. Townsley, C. Pignataro, S. Wainner, T. Seely, J. Young.

Date: March 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4817

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize anL2TPv3 encapsulation over an IP network instead.

RFC 4818 RADIUS Delegated-IPv6-Prefix Attribute

Authors: J. Salowey, R. Droms.

Date: April 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4818

This document defines a RADIUS (Remote Authentication Dial In UserService) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter.

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 4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)

Authors: M. Tuexen, R. Stewart, P. Lei.

Date: March 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4820

This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. The padding chunk is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size. The padding parameter is used to pad an SCTPINIT chunk to an arbitrary size.

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 4822 RIPv2 Cryptographic Authentication

Authors: R. Atkinson, M. Fanto.

Date: February 2007

Formats: txt html json

Obsoletes: RFC 2082

Updates: RFC 2453

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4822

This note describes a revision to the RIPv2 CryptographicAuthentication mechanism originally specified in RFC 2082. This document obsoletes RFC 2082 and updates RFC 2453. This document adds details of how the SHA family of hash algorithms can be used withRIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section.

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 4824 The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)

Authors: J. Hofmueller, Ed., A. Bachmann, Ed., IO. zmoelnig, Ed..

Date: 1 April 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4824

This document specifies a method for encapsulating and transmittingIPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS).

RFC 4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)

Authors: J. Rosenberg.

Date: May 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4825

This specification defines the Extensible Markup Language (XML)Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed byHTTP.

RFC 4826 Extensible Markup Language (XML) Formats for Representing Resource Lists

Authors: J. Rosenberg.

Date: May 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4826

In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers(URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends aSession Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents.One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XMLConfiguration Access Protocol (XCAP).

RFC 4827 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents

Authors: M. Isomaki, E. Leppanen.

Date: May 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4827

This document describes a usage of the Extensible Markup Language(XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol(SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity.

RFC 4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant

Authors: S. Floyd, E. Kohler.

Date: April 2007

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4828

This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.
TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment(RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.
Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small- packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth.

RFC 4829 Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering

Authors: J. de Oliveira, Ed., JP. Vasseur, Ed., L. Chen, C. Scoglio.

Date: April 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4829

When the establishment of a higher priority (Traffic EngineeringLabel Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select whichTE LSPs will be preempted. The preempted LSPs are then rerouted by their respective Head-end Label Switch Router (LSR). This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TELSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included.

RFC 4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM)

Authors: J. Kempf, Ed..

Date: April 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4830

Localized mobility management is a well-understood concept in theIETF, with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management.

RFC 4831 Goals for Network-Based Localized Mobility Management (NETLMM)

Authors: J. Kempf, Ed..

Date: April 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4831

In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed.

RFC 4832 Security Threats to Network-Based Localized Mobility Management (NETLMM)

Authors: C. Vogt, J. Kempf.

Date: April 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4832

This document discusses security threats to network-based localized mobility management. Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node. Threats to the former interface impact the localized mobility management protocol itself.

RFC 4833 Timezone Options for DHCP

Authors: E. Lear, P. Eggert.

Date: April 2007

Formats: txt html json

Updates: RFC 2132

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4833

Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifiesDHCP options for each of those methods. The DHCPv4 time offset option is deprecated.

RFC 4834 Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)

Authors: T. Morin, Ed..

Date: April 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4834

This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3(L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines.

RFC 4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

Authors: V. Manral.

Date: April 2007

Formats: txt json html

Obsoletes: RFC 4305

Obsoleted by: RFC 7321

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4835

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The EncapsulatingSecurity Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec SecurityAssociation (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time.

RFC 4836 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)

Authors: E. Beili.

Date: April 2007

Formats: txt html json

Obsoletes: RFC 3636

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4836

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3Medium Attachment Units (MAUs). This document obsoletes RFC 3636.It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate InternetAssigned Number Authority (IANA) maintained MIB module. In addition, management information is added to enable support for Ethernet in theFirst Mile (EFM) and 10GBASE-CX4 MAUs.

RFC 4837 Managed Objects of Ethernet Passive Optical Networks (EPON)

Authors: L. Khermosh.

Date: July 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4837

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP basedInternets. In particular, it defines objects for managing interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces.

RFC 4838 Delay-Tolerant Networking Architecture

Authors: V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, H. Weiss.

Date: April 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4838

This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group.

RFC 4839 Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF)

Authors: G. Conboy, J. Rivlin, J. Ferraiolo.

Date: April 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4839

This document serves to register a media type for the Open eBookPublication Structure (OEBPS) Package Files.

RFC 4840 Multiple Encapsulation Methods Considered Harmful

Authors: B. Aboba, Ed., E. Davies, D. Thaler.

Date: April 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4840

This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods.

RFC 4841 RFC 4181 Update to Recognize the IETF Trust

Authors: C. Heard, Ed..

Date: March 2007

Formats: txt html json

Updates: RFC 4181

Also: BCP 0111

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4841

This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust.

RFC 4842 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)

Authors: A. Malis, P. Pate, R. Cohen, Ed., D. Zelig.

Date: April 2007

Formats: txt json html

Obsoletes: RFC 5143

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4842

This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy(SONET/SDH) circuits and services over MPLS.

RFC 4843 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)

Authors: P. Nikander, J. Laganier, F. Dupont.

Date: April 2007

Formats: txt json html

Obsoleted by: RFC 7343

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4843

This document introduces Overlay Routable Cryptographic HashIdentifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application ProgrammingInterfaces (API) and not as identifiers for network location at theIP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level.Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with currentIPv6 addresses.
This document requests IANA to allocate a temporary prefix out of theIPv6 addressing space for Overlay Routable Cryptographic HashIdentifiers. By default, the prefix will be returned to IANA in2014, with continued use requiring IETF consensus.

RFC 4844 The RFC Series and RFC Editor

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 4845 Process for Publication of IAB RFCs

Authors: L. Daigle, Ed., Internet Architecture Board.

Date: July 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4845

From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC Series.

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 4847 Framework and Requirements for Layer 1 Virtual Private Networks

Authors: T. Takeda, Ed..

Date: April 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4847

This document provides a framework and service level requirements forLayer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.
The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs.

RFC 4848 Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)

Authors: L. Daigle.

Date: April 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4848

The purpose of this document is to define a new, straightforwardDynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbedU-NAPTR, this is effectively an extension of the StraightforwardNAPTR (S-NAPTR) DDDS Application.

RFC 4849 RADIUS Filter Rule Attribute

Authors: P. Congdon, M. Sanchez, B. Aboba.

Date: April 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4849

While RFC 2865 defines the Filter-Id attribute, it requires that theNetwork Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service(RADIUS). This attribute is based on the Diameter NAS-Filter-RuleAttribute Value Pair (AVP) described in RFC 4005, and theIPFilterRule syntax defined in RFC 3588.

RFC 4850 Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture

Authors: D. Wysochanski.

Date: April 2007

Formats: txt html json

Obsoleted by: RFC 7143

Updates: RFC 3720

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4850

The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs.

RFC 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 4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus

Authors: J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green.

Date: April 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4852

This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity.The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network.

RFC 4853 Cryptographic Message Syntax (CMS) Multiple Signer Clarification

Authors: R. Housley.

Date: April 2007

Formats: txt json html

Updates: RFC 3852

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4853

This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present.

RFC 4854 A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)

Authors: P. Saint-Andre.

Date: April 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4854

This document describes a Uniform Resource Name (URN) namespace for uniquely identifying Extensible Markup Language (XML) formats and protocols that provide extensions to the Extensible Messaging andPresence Protocol (XMPP) and are defined in specifications published by the XMPP Standards Foundation (XSF).

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 4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences

Authors: S. Casner.

Date: February 2007

Formats: txt json html

Obsoletes: RFC 3555

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4856

This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences.Some of these may also be used for transfer modes other than RTP.

RFC 4857 Mobile IPv4 Regional Registration

Authors: E. Fogelstroem, A. Jonsson, C. Perkins.

Date: June 2007

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4857

Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol.

RFC 4858 Document Shepherding from Working Group Last Call to Publication

Authors: H. Levkowetz, D. Meyer, L. Eggert, A. Mankin.

Date: May 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4858

This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the AreaDirector responsible for the working group has traditionally filled the shepherding role.

RFC 4859 Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object

Authors: A. Farrel.

Date: April 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4859

This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineering(RSVP-TE) signaling messages used in Multiprotocol Label Switching(MPLS) and Generalized MPLS (GMPLS) signaling.

RFC 4860 Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations

Authors: F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. Davenport.

Date: May 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4860

RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end- to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a givenPHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network.

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 4863 Wildcard Pseudowire Type

Authors: L. Martini, G. Swallow.

Date: May 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4863

Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form ofLDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these twoLSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a Wildcard PW Type to satisfy this need.

RFC 4864 Local Network Protection for IPv6

Authors: G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein.

Date: May 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4864

Although there are many perceived benefits to Network AddressTranslation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation.

RFC 4865 SMTP Submission Service Extension for Future Message Release

Authors: G. White, G. Vaudreuil.

Date: May 2007

Formats: txt html json

Updates: RFC 3463, RFC 3464

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4865

This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time.

RFC 4866 Enhanced Route Optimization for Mobile IPv6

Authors: J. Arkko, C. Vogt, W. Haddad.

Date: May 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4866

This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead.

RFC 4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs

Authors: J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie.

Date: April 2007

Formats: txt json html

Obsoletes: RFC 3267

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4867

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267.

RFC 4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec

Authors: S. Kelly, S. Frankel.

Date: May 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4868

This specification describes the use of Hashed Message AuthenticationMode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP),Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128,HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, andPRF-HMAC-SHA-512.

RFC 4869 Suite B Cryptographic Suites for IPsec

Authors: L. Law, J. Solinas.

Date: May 2007

Formats: txt html json

Obsoleted by: RFC 6379

Status: HISTORIC

DOI: 10.17487/RFC 4869

This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with theUnited States National Security Agency's Suite B specifications.

RFC 4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)

Authors: M. Delany.

Date: May 2007

Formats: txt html json

Obsoleted by: RFC 4871

Status: HISTORIC

DOI: 10.17487/RFC 4870

"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.
This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.
Proof and protection of email identity may assist in the global control of "spam" and "phishing".

RFC 4871 DomainKeys Identified Mail (DKIM) Signatures

Authors: E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas.

Date: May 2007

Formats: txt html json

Obsoletes: RFC 4870

Obsoleted by: RFC 6376

Updated by: RFC 5672

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4871

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or MailUser Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing".

RFC 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 4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents

Authors: B. Neal-Joslin, Ed., L. Howard, M. Ansari.

Date: May 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4876

This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an object class are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support.In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services.

RFC 4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture

Authors: V. Devarapalli, F. Dupont.

Date: April 2007

Formats: txt json html

Updates: RFC 3776

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4877

This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2.

RFC 4878 Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces

Authors: M. Squire.

Date: June 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4878

This document defines objects for managing Operations,Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards. The Ethernet OAM functionality is complementary to theSimple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those linkOAM functions and for providing results and status of the OAM functions to management entities.

RFC 4879 Clarification of the Third Party Disclosure Procedure in RFC 3979

Authors: T. Narten.

Date: April 2007

Formats: txt html json

Obsoleted by: RFC 8179

Updates: RFC 3979

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4879

This document clarifies and updates a single sentence in RFC 3979.Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF ExecutiveDirector notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules.

RFC 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 4881 Low-Latency Handoffs in Mobile IPv4

Authors: K. El Malki, Ed..

Date: June 2007

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4881

Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real- time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process.

RFC 4882 IP Address Location Privacy and Mobile IPv6: Problem Statement

Authors: R. Koodli.

Date: May 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4882

In this document, we discuss location privacy as applicable to MobileIPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent.

RFC 4883 Benchmarking Terminology for Resource Reservation Capable Routers

Authors: G. Feher, K. Nemeth, A. Korn, I. Cselenyi.

Date: July 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4883

The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling ofIntegrated Services (IntServ) IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements.

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 4885 Network Mobility Support Terminology

Authors: T. Ernst, H-Y. Lach.

Date: July 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4885

This document defines a terminology for discussing network mobility(NEMO) issues and solution requirements.

RFC 4886 Network Mobility Support Goals and Requirements

Authors: T. Ernst.

Date: July 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4886

Network mobility arises when a router connecting a network to theInternet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution.

RFC 4887 Network Mobility Home Network Models

Authors: P. Thubert, R. Wakikawa, V. Devarapalli.

Date: July 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4887

This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists.

RFC 4888 Network Mobility Route Optimization Problem Statement

Authors: C. Ng, P. Thubert, M. Watari, F. Zhao.

Date: July 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4888

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and HomeAgent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of MobileNetworks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind RouteOptimization (RO) for NEMO.

RFC 4889 Network Mobility Route Optimization Solution Space Analysis

Authors: C. Ng, F. Zhao, M. Watari, P. Thubert.

Date: July 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4889

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through theMobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO RouteOptimization.

RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls

Authors: E. Davies, J. Mohacsi.

Date: May 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4890

In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.
This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks.

RFC 4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels

Authors: R. Graveman, M. Parthasarathy, P. Savola, H. Tschofenig.

Date: May 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4891

This document gives guidance on securing manually configured IPv6-in-IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework.

RFC 4892 Requirements for a Mechanism Identifying a Name Server Instance

Authors: S. Woolf, D. Conrad.

Date: June 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4892

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a singleIP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism.

RFC 4893 BGP Support for Four-octet AS Number Space

Authors: Q. Vohra, E. Chen.

Date: May 2007

Formats: txt json html

Obsoleted by: RFC 6793

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4893

Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry theAutonomous System number as a four-octet entity.

RFC 4894 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec

Authors: P. Hoffman.

Date: May 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4894

This document describes how the IKEv1 (Internet Key Exchange version1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms.

RFC 4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)

Authors: M. Tuexen, R. Stewart, P. Lei, E. Rescorla.

Date: August 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4895

This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys.

RFC 4896 Signaling Compression (SigComp) Corrections and Clarifications

Authors: A. Surtees, M. West, A.B. Roach.

Date: June 2007

Formats: txt json html

Updates: RFC 3320, RFC 3321, RFC 3485

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4896

This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems.SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP).This document updates the following RFCs: RFC 3320, RFC 3321, and RFC3485.

RFC 4897 Handling Normative References to Standards-Track Documents

Authors: J. Klensin, S. Hartman.

Date: June 2007

Formats: txt json html

Updates: RFC 3967

Also: BCP 0097

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4897

The Internet Engineering Task Force (IETF) and Request for Comments(RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. The IETF agreed on a way to bypass this rule with RFC 3967. This document describes a simpler procedure for downward references to Standards-Track and Best CurrentPractice (BCP) documents, namely "note and move on". The procedure in RFC 3967 still applies for downward references to other classes of documents. In both cases, annotations should be added to suchReferences.

RFC 4898 TCP Extended Statistics MIB

Authors: M. Mathis, J. Heffner, R. Raghunarayan.

Date: May 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4898

This document describes extended performance statistics for TCP.They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself.If the bottleneck is in the network, TCP can provide specific information about its nature.

RFC 4901 Protocol Extensions for Header Compression over MPLS

Authors: J. Ash, Ed., J. Hand, Ed., A. Malis, Ed..

Date: June 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4901

This specification defines how to use Multi-Protocol Label Switching(MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP.This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to- point link.

RFC 4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP

Authors: M. Stecher.

Date: May 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4902

The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework.Previous work has focused on HTTP and work for SMTP is in progress.These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations forOPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity ofSMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the"SMTP adaptation with OPES" document.
The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date.

RFC 4903 Multi-Link Subnet Issues

Authors: D. Thaler.

Date: June 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4903

There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach.

RFC 4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)

Authors: V. Gurbani, C. Jennings.

Date: June 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4904

This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs).An extension to the tel URI is defined for this purpose.

RFC 4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks

Authors: L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed..

Date: June 2007

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 4905

This document describes methods for encapsulating the Protocol DataUnits (PDUs) of layer 2 protocols such as Frame Relay, AsynchronousTransfer Mode (ATM), or Ethernet for transport across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire EmulationEdge to Edge Working Group specifications described in RFC 4447 and related documents.

RFC 4906 Transport of Layer 2 Frames Over MPLS

Authors: L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed..

Date: June 2007

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 4906

This document describes methods for transporting the Protocol DataUnits (PDUs) of layer 2 protocols such as Frame Relay, AsynchronousTransfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so- called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents.

RFC 4907 Architectural Implications of Link Indications

Authors: B. Aboba, Ed..

Date: June 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4907

A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role of link indications within the Internet architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications.

RFC 4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO

Authors: K. Nagami, S. Uda, N. Ogashiwa, H. Esaki, R. Wakikawa, H. Ohnishi.

Date: June 2007

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4908

Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care- of Addresses (CoAs) can be used. In addition, multiple Home Agents(HAs) that are located in different places are required for redundancy.

RFC 4909 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport

Authors: L. Dondeti, Ed., D. Castleford, F. Hartung.

Date: June 2007

Formats: txt html json

Obsoleted by: RFC 5410, RFC 6309

Status: INFORMATIONAL

DOI: 10.17487/RFC 4909

This document specifies a new Multimedia Internet KEYing (MIKEY)General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast(BCAST) group's Service and Content protection specification.

RFC 4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)

Authors: S. Legg, D. Prager.

Date: July 2007

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4910

This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined.

RFC 4911 Encoding Instructions for the Robust XML Encoding Rules (RXER)

Authors: S. Legg.

Date: July 2007

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4911

This document defines encoding instructions that may be used in anAbstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) andCanonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined.

RFC 4912 Abstract Syntax Notation X (ASN.X)

Authors: S. Legg.

Date: July 2007

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4912

Abstract Syntax Notation X (ASN.X) is a semantically equivalentExtensible Markup Language (XML) representation for Abstract SyntaxNotation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the RobustXML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents.

RFC 4913 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)

Authors: S. Legg.

Date: July 2007

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4913

Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language(XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER).

RFC 4914 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER)

Authors: S. Legg.

Date: July 2007

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4914

Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language(XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER).

RFC 4915 Multi-Topology (MT) Routing in OSPF

Authors: P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay-Esnault.

Date: June 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4915

This document describes an extension to Open Shortest Path First(OSPF) in order to define independent IP topologies called Multi-Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.
An optional extension to exclude selected links from the default topology is also described.

RFC 4916 Connected Identity in the Session Initiation Protocol (SIP)

Authors: J. Elwell.

Date: June 2007

Formats: txt json html

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4916

This document provides a means for a Session Initiation Protocol(SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by anAuthentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP).

RFC 4917 Mobile IPv4 Message String Extension

Authors: V. Sastry, K. Leung, A. Patel.

Date: June 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4917

This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent toRegistration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node.

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 4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals

Authors: N. Kushalnagar, G. Montenegro, C. Schumacher.

Date: August 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4919

This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only.

RFC 4920 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE

Authors: A. Farrel, Ed., A. Satyanarayana, A. Iwata, N. Fujita, G. Ash.

Date: July 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4920

In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS(GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.
This document specifies crankback signaling extensions for use inMPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions toRSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in"Generalized Multi-Protocol Label Switching (GMPLS) SignalingFunctional Description", RFC 3473. These extensions mean that theLSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time.

RFC 4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network

Authors: F. Baker, P. Bose.

Date: August 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4923

Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework forIntegrated Services operation over Diffserv networks as described inRFC 2998.

RFC 4924 Reflections on Internet Transparency

Authors: B. Aboba, Ed., E. Davies.

Date: July 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4924

This document provides a review of previous IAB statements onInternet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts.

RFC 4925 Softwire Problem Statement

Authors: X. Li, Ed., S. Dawkins, Ed., D. Ward, Ed., A. Durand, Ed..

Date: July 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4925

This document captures the problem statement for the SoftwiresWorking Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope.

RFC 4926 A URN Namespace for GEANT

Authors: T. Kalin, M. Molina.

Date: July 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4926

This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing EuropeanResearch and academic networks, for naming persistent resources defined by GEANT, the Consortium of European Academic and ResearchNetworks, its projects, activities, working groups, and other designated subordinates.

RFC 4927 Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering

Authors: J.-L. Le Roux, Ed..

Date: June 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4927

For scalability purposes, a network may comprise multiple InteriorGateway Protocol (IGP) areas. An inter-area Traffic Engineered LabelSwitched Path (TE-LSP) is an LSP that transits through at least twoIGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths. The PCE CommunicationProtocol (PCECP) is used to communicate computation requests fromPath Computation Clients (PCCs) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE CommunicationProtocol.

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 4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures

Authors: L. Andersson, Ed., A. Farrel, Ed..

Date: June 2007

Formats: txt html json

Also: BCP 0129

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4929

This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards DevelopmentOrganizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes.

RFC 4930 Extensible Provisioning Protocol (EPP)

Authors: S. Hollenbeck.

Date: May 2007

Formats: txt html json

Obsoletes: RFC 3730

Obsoleted by: RFC 5730

Status: DRAFT STANDARD

DOI: 10.17487/RFC 4930

This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 3730.

RFC 4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping

Authors: S. Hollenbeck.

Date: May 2007

Formats: txt html json

Obsoletes: RFC 3731

Obsoleted by: RFC 5731

Status: DRAFT STANDARD

DOI: 10.17487/RFC 4931

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.This document obsoletes RFC 3731.

RFC 4932 Extensible Provisioning Protocol (EPP) Host Mapping

Authors: S. Hollenbeck.

Date: May 2007

Formats: txt json html

Obsoletes: RFC 3732

Obsoleted by: RFC 5732

Status: DRAFT STANDARD

DOI: 10.17487/RFC 4932

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.This document obsoletes RFC 3732.

RFC 4933 Extensible Provisioning Protocol (EPP) Contact Mapping

Authors: S. Hollenbeck.

Date: May 2007

Formats: txt json html

Obsoletes: RFC 3733

Obsoleted by: RFC 5733

Status: DRAFT STANDARD

DOI: 10.17487/RFC 4933

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733.

RFC 4934 Extensible Provisioning Protocol (EPP) Transport Over TCP

Authors: S. Hollenbeck.

Date: May 2007

Formats: txt html json

Obsoletes: RFC 3734

Obsoleted by: RFC 5734

Status: DRAFT STANDARD

DOI: 10.17487/RFC 4934

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. This document obsoletes RFC 3734.

RFC 4935 Fibre Channel Fabric Configuration Server MIB

Authors: C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai.

Date: August 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4935

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 information related to the Fabric Configuration Server function of a Fibre Channel network.

RFC 4936 Fibre Channel Zone Server MIB

Authors: C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai.

Date: August 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4936

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 information related to a Fibre Channel Zone Server.

RFC 4937 IANA Considerations for PPP over Ethernet (PPPoE)

Authors: P. Arberg, V. Mammoliti.

Date: June 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4937

This document describes the IANA considerations for the PPP overEthernet (PPPoE) protocol.

RFC 4938 PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics

Authors: B. Berry, H. Holgate.

Date: June 2007

Formats: txt html json

Obsoleted by: RFC 5578

Status: INFORMATIONAL

DOI: 10.17487/RFC 4938

This document extends the Point-to-Point over Ethernet (PPPoE)Protocol with a credit-based flow control mechanism and Link QualityMetric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links.

RFC 4939 Definitions of Managed Objects for iSNS (Internet Storage Name Service)

Authors: K. Gibbons, G. Ramkumar, S. Kipp.

Date: July 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4939

The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (InternetFibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server.

RFC 4940 IANA Considerations for OSPF

Authors: K. Kompella, B. Fenner.

Date: July 2007

Formats: txt json html

Also: BCP 0130

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4940

This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries.

RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6

Authors: T. Narten, R. Draves, S. Krishnan.

Date: September 2007

Formats: txt json html

Obsoletes: RFC 3041

Obsoleted by: RFC 8981

Status: DRAFT STANDARD

DOI: 10.17487/RFC 4941

Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.

RFC 4942 IPv6 Transition/Co-existence Security Considerations

Authors: E. Davies, S. Krishnan, P. Savola.

Date: September 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4942

The transition from a pure IPv4 network to a network where IPv4 andIPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.

RFC 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful

Authors: S. Roy, A. Durand, J. Paugh.

Date: September 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4943

This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6(IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic withIPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm.

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 4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX

Authors: B. Korver.

Date: August 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4945

The Internet Key Exchange (IKE) and Public Key Infrastructure forX.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec.

RFC 4946 Atom License Extension

Authors: J. Snell.

Date: July 2007

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4946

This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries.

RFC 4947 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks

Authors: G. Fairhurst, M. Montpetit.

Date: July 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4947

This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions.
In MPEG-2 Networks, an IP address must be associated with a Packet ID(PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced TelevisionSystems Committee), DOCSIS (Data-Over-Cable Service InterfaceSpecifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol.

RFC 4948 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006

Authors: L. Andersson, E. Davies, L. Zhang.

Date: August 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4948

This document reports the outcome of a workshop held by the InternetArchitecture Board (IAB) on Unwanted Internet Traffic. The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA.The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions. It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic.

RFC 4949 Internet Security Glossary, Version 2

Authors: R. Shirey.

Date: August 2007

Formats: txt json html

Obsoletes: RFC 2828

Also: FYI 0036

Status: INFORMATIONAL

DOI: 10.17487/RFC 4949

This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process(RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.

RFC 4950 ICMP Extensions for Multiprotocol Label Switching

Authors: R. Bonica, D. Gan, D. Tappan, C. Pignataro.

Date: August 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4950

This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits LabelSwitching Routers to append MPLS information to ICMP messages, and has already been widely deployed.

RFC 4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"

Authors: V. Jain, Ed..

Date: August 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4951

Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints. Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection.When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity.

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 4953 Defending TCP Against Spoofing Attacks

Authors: J. Touch.

Date: July 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4953

Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation ofTCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth- delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment.This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections.

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 4955 DNS Security (DNSSEC) Experiments

Authors: D. Blacka.

Date: July 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4955

This document describes a methodology for deploying alternate, non- backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standardDNSSEC.

RFC 4956 DNS Security (DNSSEC) Opt-In

Authors: R. Arends, M. Kosters, D. Blacka.

Date: July 2007

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4956

In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones.

RFC 4957 Link-Layer Event Notifications for Detecting Network Attachments

Authors: S. Krishnan, Ed., N. Montavont, E. Njedjou, S. Veerepalli, A. Yegin, Ed..

Date: August 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4957

Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes.This document provides a non-exhaustive catalogue of information available from well-known access technologies.

RFC 4958 A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain

Authors: K. Carlberg.

Date: July 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4958

This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented.

RFC 4959 IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response

Authors: R. Siemborski, A. Gulbrandsen.

Date: September 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4959

To date, the Internet Message Access Protocol (IMAP) has used aSimple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round-trip costs are high.
This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command.

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 4961 Symmetric RTP / RTP Control Protocol (RTCP)

Authors: D. Wing.

Date: July 2007

Formats: txt json html

Also: BCP 0131

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4961

This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP ControlProtocol (RTCP) sessions, commonly called "symmetric RTP" and"symmetric RTCP".

RFC 4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management

Authors: R. Housley, B. Aboba.

Date: July 2007

Formats: txt html json

Also: BCP 0132

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 4962

This document provides guidance to designers of Authentication,Authorization, and Accounting (AAA) key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, andAccounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management.

RFC 4963 IPv4 Reassembly Errors at High Data Rates

Authors: J. Heffner, M. Mathis, B. Chandler.

Date: July 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4963

IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations.

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 4965 CableLabs - IETF Standardization Collaboration

Authors: J-F. Mule, W. Townsley.

Date: September 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4965

This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the CableTelevision Laboratories, Inc. (CableLabs).

RFC 4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status

Authors: C. Aoun, E. Davies.

Date: July 2007

Formats: txt html json

Obsoletes: RFC 2766

Status: INFORMATIONAL

DOI: 10.17487/RFC 4966

This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network AddressTranslator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 fromProposed Standard to Historic status.

RFC 4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier

Authors: B. Rosen.

Date: July 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4967

RFC 3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or'sips:' URI.

RFC 4968 Analysis of IPv6 Link Models for 802.16 Based Networks

Authors: S. Madanapalli, Ed..

Date: August 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4968

This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks.

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 4970 Extensions to OSPF for Advertising Optional Router Capabilities

Authors: A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer.

Date: July 2007

Formats: txt json html

Obsoleted by: RFC 7770

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4970

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 andOSPFv3 for advertising optional router capabilities. A new RouterInformation (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaqueLSA type ID. In OSPFv3, the RI LSA will be implemented with a newLSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)).

RFC 4971 Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information

Authors: JP. Vasseur, Ed., N. Shen, Ed., R. Aggarwal, Ed..

Date: July 2007

Formats: txt json html

Obsoleted by: RFC 7981

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4971

This document defines a new optional Intermediate System toIntermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.

RFC 4972 Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership

Authors: JP. Vasseur, Ed., JL. Leroux, Ed., S. Yasukawa, S. Previdi, P. Psenak, P. Mabbey.

Date: July 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4972

The setup of a full mesh of Multi-Protocol Label Switching (MPLS)Traffic Engineering (TE) Label Switched Paths (LSP) among a set ofLabel Switch Routers (LSR) is a common deployment scenario of MPLSTraffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of a potentially large number of TELSPs (on the order of the square of the number of LSRs). This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and OpenShortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs.

RFC 4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering

Authors: P. Srisuresh, P. Joseph.

Date: July 2007

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4973

This document defines OSPF-xTE, an experimental traffic engineering(TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE Link State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that non-TE nodes in the AS are unaffected by the TE LSAs.OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as Synchronous Optical Network (SONET) / Time DivisionMultiplexing (TDM) and optical networks.

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 4977 Problem Statement: Dual Stack Mobility

Authors: G. Tsirtsis, H. Soliman.

Date: August 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4977

This document discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems.Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the MobileIPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node.

RFC 4978 The IMAP COMPRESS Extension

Authors: A. Gulbrandsen.

Date: August 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4978

The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed.

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 4980 Analysis of Multihoming in Network Mobility Support

Authors: C. Ng, T. Ernst, E. Paik, M. Bagnulo.

Date: October 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4980

This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO BasicSupport). Recommendations are offered on how to address these issues.

RFC 4981 Survey of Research towards Robust Peer-to-Peer Networks: Search Methods

Authors: J. Risson, T. Moors.

Date: September 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4981

The pace of research on peer-to-peer (P2P) networking in the last five years warrants a critical survey. P2P has the makings of a disruptive technology -- it can aggregate enormous storage and processing resources while minimizing entry and scaling costs.
Failures are common amongst massive numbers of distributed peers, though the impact of individual failures may be less than in conventional architectures. Thus, the key to realizing P2P's potential in applications other than casual file sharing is robustness.
P2P search methods are first couched within an overall P2P taxonomy.P2P indexes for simple key lookup are assessed, including those based on Plaxton trees, rings, tori, butterflies, de Bruijn graphs, and skip graphs. Similarly, P2P indexes for keyword lookup, information retrieval and data management are explored. Finally, early efforts to optimize range, multi-attribute, join, and aggregation queries over P2P indexes are reviewed. Insofar as they are available in the primary literature, robustness mechanisms and metrics are highlighted throughout. However, the low-level mechanisms that most affect robustness are not well isolated in the literature. Recommendations are given for future research.

RFC 4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)

Authors: M. Bagnulo, J. Arkko.

Date: July 2007

Formats: txt html json

Updates: RFC 3972

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4982

This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms.

RFC 4983 Fibre Channel Registered State Change Notification (RSCN) MIB

Authors: C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai.

Date: August 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4983

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 information related to the management of Fibre Channel's Registered State ChangeNotifications (RSCNs).

RFC 4984 Report from the IAB Workshop on Routing and Addressing

Authors: D. Meyer, Ed., L. Zhang, Ed., K. Fall, Ed..

Date: September 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4984

This document reports the outcome of the Routing and AddressingWorkshop that was held by the Internet Architecture Board (IAB) onOctober 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work.

RFC 4985 Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name

Authors: S. Santesson.

Date: August 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4985

This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record.

RFC 4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover

Authors: H. Eland, R. Mundy, S. Crocker, S. Krishnaswamy.

Date: August 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4986

Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones.For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers.

RFC 4987 TCP SYN Flooding Attacks and Common Mitigations

Authors: W. Eddy.

Date: August 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 4987

This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations.

RFC 4988 Mobile IPv4 Fast Handovers

Authors: R. Koodli, C. Perkins.

Date: October 2007

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 4988

This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations.Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address.

RFC 4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks

Authors: K. Shiomoto, R. Papneja, R. Rabbat.

Date: September 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 4990

This document clarifies the use of addresses in GeneralizedMultiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers(LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.
The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS andGMPLS Traffic Engineering (TE) Management Information Base (MIB) modules.
This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs.

RFC 4991 A Common Schema for Internet Registry Information Service Transfer Protocols

Authors: A. Newton.

Date: August 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4991

This document describes an XML Schema for use by Internet RegistryInformation Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms.

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 4993 A Lightweight UDP Transfer Protocol for the Internet Registry Information Service

Authors: A. Newton.

Date: August 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4993

This document describes a lightweight UDP transfer protocol for theInternet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet.

RFC 4994 DHCPv6 Relay Agent Echo Request Option

Authors: S. Zeng, B. Volz, K. Kinnear, J. Brzozowski.

Date: September 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4994

This memo defines a Relay Agent Echo Request option for the DynamicHost Configuration Protocol for IPv6 (DHCPv6). The option allows aDHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent.

RFC 4995 The RObust Header Compression (ROHC) Framework

Authors: L-E. Jonsson, G. Pelletier, K. Sandlund.

Date: July 2007

Formats: txt json html

Obsoleted by: RFC 5795

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4995

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.

RFC 4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)

Authors: G. Pelletier, K. Sandlund, L-E. Jonsson, M. West.

Date: July 2007

Formats: txt html json

Obsoleted by: RFC 6846

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4996

This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.
ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.

RFC 4997 Formal Notation for RObust Header Compression (ROHC-FN)

Authors: R. Finking, G. Pelletier.

Date: July 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4997

This document defines Robust Header Compression - Formal Notation(ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work.

RFC 4998 Evidence Record Syntax (ERS)

Authors: T. Gondrom, R. Brandner, U. Pordesch.

Date: August 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 4998

In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of anEvidence Record, a structure designed to support long-term non- repudiation of existence of data.

RFC 5000 Internet Official Protocol Standards

Authors: RFC Editor.

Date: May 2008

Formats: txt html json

Obsoletes: RFC 3700

Obsoleted by: RFC 7100

Status: HISTORIC

DOI: 10.17487/RFC 5000

This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, andExperimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred.
For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily.

RFC 5001 DNS Name Server Identifier (NSID) Option

Authors: R. Austein.

Date: August 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5001

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a singleIP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself.This note defines a protocol extension to support this functionality.

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 5003 Attachment Individual Identifier (AII) Types for Aggregation

Authors: C. Metz, L. Martini, F. Balus, J. Sugimoto.

Date: September 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5003

The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and VirtualPrivate Network (VPN) auto-discovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need.

RFC 5004 Avoid BGP Best Path Transitions from One External to Another

Authors: E. Chen, S. Sangli.

Date: September 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5004

In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn.

RFC 5005 Feed Paging and Archiving

Authors: M. Nottingham.

Date: September 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5005

This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents.This includes "paged" feeds for piecemeal access, "archived" feeds that allow reconstruction of the feed's contents, and feeds that are explicitly "complete".

RFC 5006 IPv6 Router Advertisement Option for DNS Configuration

Authors: J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli.

Date: September 2007

Formats: txt json html

Obsoleted by: RFC 6106

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5006

This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses toIPv6 hosts.

RFC 5007 DHCPv6 Leasequery

Authors: J. Brzozowski, K. Kinnear, B. Volz, S. Zeng.

Date: September 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5007

This document specifies a leasequery exchange for the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6.

RFC 5008 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)

Authors: R. Housley, J. Solinas.

Date: September 2007

Formats: txt html json

Obsoleted by: RFC 6318

Status: HISTORIC

DOI: 10.17487/RFC 5008

This document specifies the conventions for using the United StatesNational Security Agency's Suite B algorithms in Secure/MultipurposeInternet Mail Extensions (S/MIME) as specified in RFC 3851.

RFC 5009 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media

Authors: R. Ejza.

Date: September 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5009

This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European TelecommunicationsStandards Institute (ETSI) Telecommunications and Internet-convergedServices and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation PartnershipProject (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state.

RFC 5010 The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption

Authors: K. Kinnear, M. Normoyle, M. Stapp.

Date: September 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5010

This memo defines a new suboption of the Dynamic Host ConfigurationProtocol (DHCP) relay agent information option that allows the DHCP relay to specify flags for the forwarded packet. One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet. This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast.

RFC 5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors

Authors: M. StJohns.

Date: September 2007

Formats: txt html json

Also: STD 0074

Status: INTERNET STANDARD

DOI: 10.17487/RFC 5011

This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).
This mechanism will require changes to resolver management behavior(but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record.

RFC 5012 Requirements for Emergency Context Resolution with Internet Technologies

Authors: H. Schulzrinne, R. Marshall, Ed..

Date: January 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5012

This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, whereInternet protocols are used end to end.

RFC 5013 The Dublin Core Metadata Element Set

Authors: J. Kunze, T. Baker.

Date: August 2007

Formats: txt json html

Obsoletes: RFC 2413

Status: INFORMATIONAL

DOI: 10.17487/RFC 5013

This document defines fifteen metadata elements for resource description in a cross-disciplinary information environment.

RFC 5014 IPv6 Socket API for Source Address Selection

Authors: E. Nordmark, S. Chakrabarti, J. Laganier.

Date: September 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5014

The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API.However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents. This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm. The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication. It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses.

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 5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol

Authors: M. Thomas.

Date: October 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5016

DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable(SHOULD).

RFC 5017 MIB Textual Conventions for Uniform Resource Identifiers (URIs)

Authors: D. McWalter, Ed..

Date: September 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5017

This MIB module defines textual conventions to represent STD 66Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s).

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 5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute

Authors: K. Zeilenga.

Date: August 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5020

This document describes the Lightweight Directory Access Protocol(LDAP) / X.500 'entryDN' operational attribute. The attribute provides a copy of the entry's distinguished name for use in attribute value assertions.

RFC 5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP

Authors: S. Josefsson.

Date: August 2007

Formats: txt html json

Updates: RFC 4120

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5021

This document describes an extensibility mechanism for the KerberosV5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiateTCP-specific Kerberos extensions.

RFC 5022 Media Server Control Markup Language (MSCML) and Protocol

Authors: J. Van Dyke, E. Burger, Ed., A. Spitzer.

Date: September 2007

Formats: txt json html

Obsoletes: RFC 4722

Status: INFORMATIONAL

DOI: 10.17487/RFC 5022

Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework.

RFC 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 5025 Presence Authorization Rules

Authors: J. Rosenberg.

Date: December 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5025

Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration AccessProtocol (XCAP), although other techniques are permitted.

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 5027 Security Preconditions for Session Description Protocol (SDP) Media Streams

Authors: F. Andreasen, D. Wing.

Date: October 2007

Formats: txt json html

Updates: RFC 3312

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5027

This document defines a new security precondition for the SessionDescription Protocol (SDP) precondition framework described in RFCs3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully.

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 5029 Definition of an IS-IS Link Attribute Sub-TLV

Authors: JP. Vasseur, S. Previdi.

Date: September 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5029

This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics.

RFC 5030 Mobile IPv4 RADIUS Requirements

Authors: M. Nakhjiri, Ed., K. Chowdhury, A. Lior, K. Leung.

Date: October 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5030

This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service(RADIUS) extensions to support Mobile IPv4. The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures.

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 5032 WITHIN Search Extension to the IMAP Protocol

Authors: E. Burger, Ed..

Date: September 2007

Formats: txt json html

Updates: RFC 3501

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5032

This document describes the WITHIN extension to IMAP SEARCH. IMAPSEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses.

RFC 5033 Specifying New Congestion Control Algorithms

Authors: S. Floyd, M. Allman.

Date: August 2007

Formats: txt json html

Also: BCP 0133

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5033

The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF.

RFC 5034 The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism

Authors: R. Siemborski, A. Menon-Sen.

Date: July 2007

Formats: txt html json

Obsoletes: RFC 1734

Updates: RFC 2449

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5034

This document defines a profile of the Simple Authentication andSecurity Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to 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 document seeks to consolidate the information related to POP3AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained inSection 6.3 of RFC 2449.

RFC 5035 Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility

Authors: J. Schaad.

Date: August 2007

Formats: txt html json

Updates: RFC 2634

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5035

In the original Enhanced Security Services for S/MIME document (RFC2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose.

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 5037 Experience with the Label Distribution Protocol (LDP)

Authors: L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed..

Date: October 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5037

The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol). Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264.

RFC 5038 The Label Distribution Protocol (LDP) Implementation Survey Results

Authors: B. Thomas, L. Andersson.

Date: October 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5038

Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops. A fundamental concept in MPLS is that two Label 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 DistributionProtocol (as described in RFC 3036) , by which one LSR informs another of label bindings it has made. One such protocol, calledLDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey ofLDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard.

RFC 5039 The Session Initiation Protocol (SIP) and Spam

Authors: J. Rosenberg, C. Jennings.

Date: January 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5039

Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email.It can affect any system that enables user-to-user communications.The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP.

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 5050 Bundle Protocol Specification

Authors: K. Scott, S. Burleigh.

Date: November 2007

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5050

This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).
This document was produced within the IRTF's Delay TolerantNetworking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information.

RFC 5051 i;unicode-casemap - Simple Unicode Collation Algorithm

Authors: M. Crispin.

Date: October 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5051

This document describes "i;unicode-casemap", a simple case- insensitive collation for Unicode strings. It provides equality, substring, and ordering operations.

RFC 5052 Forward Error Correction (FEC) Building Block

Authors: M. Watson, M. Luby, L. Vicisano.

Date: August 2007

Formats: txt html json

Obsoletes: RFC 3452

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5052

This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described.The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) inReliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452.

RFC 5053 Raptor Forward Error Correction Scheme for Object Delivery

Authors: M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer.

Date: October 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5053

This document describes a Fully-Specified Forward Error Correction(FEC) scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects.
Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols.
The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated.

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 5055 Server-Based Certificate Validation Protocol (SCVP)

Authors: T. Freeman, R. Housley, A. Malpani, D. Cooper, W. Polk.

Date: December 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5055

The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server. The path construction or validation(e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies.

RFC 5056 On the Use of Channel Bindings to Secure Channels

Authors: N. Williams.

Date: November 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5056

The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.
This document discusses and formalizes the concept of channel binding to secure channels.

RFC 5057 Multiple Dialog Usages in the Session Initiation Protocol

Authors: R. Sparks.

Date: November 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5057

Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.
This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them.
This is an informative document and makes no normative statements of any kind.

RFC 5058 Explicit Multicast (Xcast) Concepts and Options

Authors: R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms.

Date: November 2007

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5058

While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describesXcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.
This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification.

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 5060 Protocol Independent Multicast MIB

Authors: R. Sivaramu, J. Lingard, D. McWalter, B. Joshi, A. Kessler.

Date: January 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5060

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 theProtocol Independent Multicast (PIM) protocols: PIM-SM (Sparse Mode),BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC2934.

RFC 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration

Authors: R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, M. Kozuka.

Date: September 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5061

A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. StreamControl Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures.This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint.

RFC 5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures

Authors: R. Stewart, M. Tuexen, G. Camarillo.

Date: September 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5062

This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC4460). These techniques are included in RFC 4960, which obsoletesRFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC4960.

RFC 5063 Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart

Authors: A. Satyanarayana, Ed., R. Rahman, Ed..

Date: October 2007

Formats: txt html json

Updates: RFC 2961, RFC 3473

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5063

This document describes extensions to the Resource ReservationProtocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on thePath message last sent by the node being restarted.
Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.
The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.
These extensions are not used to create or restore data plane state.
The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during theRecovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs).

RFC 5064 The Archived-At Message Header Field

Authors: M. Duerst.

Date: December 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5064

This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message.

RFC 5065 Autonomous System Confederations for BGP

Authors: P. Traina, D. McPherson, J. Scudder.

Date: August 2007

Formats: txt json html

Obsoletes: RFC 3065

Status: DRAFT STANDARD

DOI: 10.17487/RFC 5065

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/InternetProtocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.
This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.
This document obsoletes RFC 3065.

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 5067 Infrastructure ENUM Requirements

Authors: S. Lind, P. Pfautz.

Date: November 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5067

This document provides requirements for "infrastructure" or "carrier"ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.)

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 5069 Security Threats and Requirements for Emergency Call Marking and Mapping

Authors: T. Taylor, Ed., H. Tschofenig, H. Schulzrinne, M. Shanmugam.

Date: January 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5069

This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to UniversalResource Identifiers (URIs) that point to Public Safety AnsweringPoints (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.
Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls.

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 5071 Dynamic Host Configuration Protocol Options Used by PXELINUX

Authors: D. Hankins.

Date: December 2007

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5071

This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211.

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 5073 IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities

Authors: J.P. Vasseur, Ed., J.L. Le Roux, Ed..

Date: December 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5073

It is highly desired, in several cases, to take into account TrafficEngineering (TE) node capabilities during Multi Protocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) Traffic EngineeredLabel Switched Path (TE-LSP) selection, such as, for instance, the capability to act as a branch Label Switching Router (LSR) of aPoint-To-MultiPoint (P2MP) LSP. This requires advertising these capabilities within the Interior Gateway Protocol (IGP). For that purpose, this document specifies Open Shortest Path First (OSPF) andIntermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities.

RFC 5074 DNSSEC Lookaside Validation (DLV)

Authors: S. Weiler.

Date: November 2007

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 5074

DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNSSecurity (DNSSEC) trust anchors outside of the DNS delegation chain.It allows validating resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or don't publishDelegation Signer (DS) records for their children.

RFC 5075 IPv6 Router Advertisement Flags Option

Authors: B. Haberman, Ed., R. Hinden.

Date: November 2007

Formats: txt json html

Obsoleted by: RFC 5175

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5075

The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available.

RFC 5076 ENUM Validation Information Mapping for the Extensible Provisioning Protocol

Authors: B. Hoeneisen.

Date: December 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5076

This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on.Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names.

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 5078 IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline

Authors: S. Dawkins.

Date: October 2007

Formats: txt json html

Obsoleted by: RFC 7437

Updates: RFC 3777

Status: INFORMATIONAL

DOI: 10.17487/RFC 5078

RFC 3777 defines the Nominations and Recall Committee's (NomCom's) operation, and includes a sample timeline for major steps in theNomCom process that meets the minimum normative requirements for the process. Recent NomComs have been scheduling based on the sample timeline, and the chairs of the last three NomComs -- Danny McPherson(2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) -- have all reported that this timeline is very aggressive and suggested starting earlier. This document restructures the sample timeline, but makes no normative process changes.

RFC 5079 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)

Authors: J. Rosenberg.

Date: December 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5079

The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose.

RFC 5080 Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes

Authors: D. Nelson, A. DeKok.

Date: December 2007

Formats: txt json html

Updates: RFC 2865, RFC 2866, RFC 2869, RFC 3579

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5080

This document describes common issues seen in Remote AuthenticationDial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified.

RFC 5081 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication

Authors: N. Mavrogiannopoulos.

Date: November 2007

Formats: txt json html

Obsoleted by: RFC 6091

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5081

This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol.

RFC 5082 The Generalized TTL Security Mechanism (GTSM)

Authors: V. Gill, J. Heasley, D. Meyer, P. Savola, Ed., C. Pignataro.

Date: October 2007

Formats: txt html json

Obsoletes: RFC 3682

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5082

The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC3682.

RFC 5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type

Authors: R. Housley.

Date: November 2007

Formats: txt html json

Updates: RFC 3852

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5083

This document describes an additional content type for theCryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes.All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type.

RFC 5084 Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)

Authors: R. Housley.

Date: November 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5084

This document specifies the conventions for using the AES-CCM and theAES-GCM authenticated encryption algorithms with the CryptographicMessage Syntax (CMS) authenticated-enveloped-data content type.

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 5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)

Authors: A. Vainshtein, Ed., I. Sasson, E. Metz, T. Frost, P. Pate.

Date: December 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5086

This document describes a method for encapsulating structured (NxDS0)Time Division Multiplexed (TDM) signals as pseudowires over packet- switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC4553).

RFC 5087 Time Division Multiplexing over IP (TDMoIP)

Authors: Y(J). Stein, R. Shashoua, R. Insler, M. Anavi.

Date: December 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5087

Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs). Being structure-aware, TDMoIP is able to ensureTDM structure integrity, and thus withstand network degradations better than structure-agnostic transport. Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation. Accesibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling.

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 5090 RADIUS Extension for Digest Authentication

Authors: B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck.

Date: February 2008

Formats: txt json html

Obsoletes: RFC 4590

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5090

This document defines an extension to the Remote AuthenticationDial-In User Service (RADIUS) protocol to enable support of DigestAuthentication, for use with HTTP-style protocols like the SessionInitiation Protocol (SIP) and HTTP.

RFC 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 5093 BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)

Authors: G. Hunt.

Date: December 2007

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5093

This document describes an RTCP XR report block, which reports packet transport parameters. The report block was developed by BT for pre- standards use in BT's next-generation network. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with theSpecification Required policy of RFC 3611. This specification does not standardise the new report block for use outside BT's network.

RFC 5094 Mobile IPv6 Vendor Specific Option

Authors: V. Devarapalli, A. Patel, K. Leung.

Date: December 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5094

There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor-specific mobility option.

RFC 5095 Deprecation of Type 0 Routing Headers in IPv6

Authors: J. Abley, P. Savola, G. Neville-Neil.

Date: December 2007

Formats: txt json html

Updates: RFC 2460, RFC 4294

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5095

The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6Type 0 Routing Headers, in light of this security concern.

RFC 5096 Mobile IPv6 Experimental Messages

Authors: V. Devarapalli.

Date: December 2007

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5096

This document defines a new experimental Mobility Header message and a Mobility option that can be used for experimental extensions to theMobile IPv6 protocol.

RFC 5097 MIB for the UDP-Lite protocol

Authors: G. Renker, G. Fairhurst.

Date: January 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5097

This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite). It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite. UDP-Lite resemblesUDP, but differs from the semantics of UDP by the addition of a single option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram.

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 5101 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information

Authors: B. Claise, Ed..

Date: January 2008

Formats: txt json html

Obsoleted by: RFC 7011

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5101

This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how theIPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIXCollecting Process.

RFC 5102 Information Model for IP Flow Information Export

Authors: J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer.

Date: January 2008

Formats: txt html json

Obsoleted by: RFC 7012

Updated by: RFC 6313

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5102

This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and theExporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications.

RFC 5103 Bidirectional Flow Export Using IP Flow Information Export (IPFIX)

Authors: B. Trammell, E. Boschi.

Date: January 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5103

This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow InformationExport (IPFIX) protocol, representing each Biflow using a single FlowRecord.

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 5105 ENUM Validation Token Format Definition

Authors: O. Lendl.

Date: December 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5105

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes a signed XML data format -- the Validation Token -- with whichValidation Entities can convey successful completion of a validation procedure in a secure fashion.

RFC 5106 The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method

Authors: H. Tschofenig, D. Kroeselberg, A. Pashalidis, Y. Ohba, F. Bersani.

Date: February 2008

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5106

This document specifies EAP-IKEv2, an Extensible AuthenticationProtocol (EAP) method that is based on the Internet Key Exchange(IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode.

RFC 5107 DHCP Server Identifier Override Suboption

Authors: R. Johnson, J. Kumarasamy, K. Kinnear, M. Stapp.

Date: February 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5107

This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for theServer Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such thatRENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include theRelay Agent option with appropriate suboptions even on DHCP RENEW messages.

RFC 5109 RTP Payload Format for Generic Forward Error Correction

Authors: A. Li, Ed..

Date: December 2007

Formats: txt json html

Obsoletes: RFC 2733, RFC 3009

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5109

This document specifies a payload format for generic Forward ErrorCorrection (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009.

RFC 5110 Overview of the Internet Multicast Routing Architecture

Authors: P. Savola.

Date: January 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5110

This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.
This memo also reclassifies several older RFCs to Historic. TheseRFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse.

RFC 5111 Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF)

Authors: B. Aboba, L. Dondeti.

Date: January 2008

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5111

This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group. ExploratoryGroups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather(BOF) session and Working Group creation. Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension.

RFC 5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)

Authors: M. Garcia-Martin.

Date: January 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5112

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents. SIP can be compressed by usingSignaling Compression (SigComp), which is enhanced by using the SIP/Session Description Protocol (SDP) dictionary to achieve better compression rates. However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency. The dictionary is compression-algorithm independent.

RFC 5113 Network Discovery and Selection Problem

Authors: J. Arkko, B. Aboba, J. Korhonen, Ed., F. Bari.

Date: January 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5113

When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network. This document defines the network discovery and selection problem, dividing it into multiple sub- problems. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed.

RFC 5114 Additional Diffie-Hellman Groups for Use with IETF Standards

Authors: M. Lepinski, S. Kent.

Date: January 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5114

This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell(SSH), Transport Layer Security (TLS), and Internet Key Exchange(IKE).
All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman orElliptic Curve Diffie-Hellman cryptography.
These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal InformationProcessing Standard (FIPS) validation of implementations that make use of these groups.

RFC 5115 Telephony Routing over IP (TRIP) Attribute for Resource Priority

Authors: K. Carlberg, P. O'Hanlon.

Date: January 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5115

This document defines a new attribute for the Telephony Routing overIP (TRIP) protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in theU.S. and Government Telephone Preference Scheme (GTPS) in the U.K.The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field.

RFC 5116 An Interface and Algorithms for Authenticated Encryption

Authors: D. McGrew.

Date: January 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5116

This document defines algorithms for Authenticated Encryption withAssociated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations.

RFC 5117 RTP Topologies

Authors: M. Westerlund, S. Wenger.

Date: January 2008

Formats: txt html json

Obsoleted by: RFC 7667

Status: INFORMATIONAL

DOI: 10.17487/RFC 5117

This document discusses multi-endpoint topologies used in Real-timeTransport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.

RFC 5118 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)

Authors: V. Gurbani, C. Boulton, R. Sparks.

Date: February 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5118

This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of anIPv6-enabled SIP implementation.

RFC 5119 A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE)

Authors: T. Edwards.

Date: February 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5119

This document describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE) for naming persistent resources that SMPTE produces or manages. A subnamespace for Universal Labels is specifically described.

RFC 5120 M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)

Authors: T. Przygienda, N. Shen, N. Sheth.

Date: February 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5120

This document describes an optional mechanism within IntermediateSystem to Intermediate Systems (IS-ISs) used today by many ISPs forIGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology.

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 5122 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)

Authors: P. Saint-Andre.

Date: February 2008

Formats: txt html json

Obsoletes: RFC 4622

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5122

This document defines the use of Internationalized ResourceIdentifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via theExtensible Messaging and Presence Protocol (XMPP).
This document obsoletes RFC 4622.

RFC 5123 Considerations in Validating the Path in BGP

Authors: R. White, B. Akyol.

Date: February 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5123

This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path.

RFC 5124 Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)

Authors: J. Ott, E. Carrara.

Date: February 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5124

An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback.

RFC 5125 Reclassification of RFC 3525 to Historic

Authors: T. Taylor.

Date: February 2008

Formats: txt json html

Obsoletes: RFC 3525

Status: INFORMATIONAL

DOI: 10.17487/RFC 5125

This document reclassifies RFC 3525, Gateway Control Protocol Version1, to Historic Status. This memo also obsoletes RFC 3525.

RFC 5126 CMS Advanced Electronic Signatures (CAdES)

Authors: D. Pinkas, N. Pope, J. Ross.

Date: March 2008

Formats: txt html json

Obsoletes: RFC 3126

Status: INFORMATIONAL

DOI: 10.17487/RFC 5126

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny(i.e., repudiates) the validity of the signature.
The format can be considered as an extension to RFC 3852 and RFC2634, where, when appropriate, additional signed and unsigned attributes have been defined.
The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS AdvancedElectronic Signatures -- CAdES) and is technically equivalent to it.
The technical contents of this specification are maintained by ETSI.The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx

RFC 5127 Aggregation of Diffserv Service Classes

Authors: K. Chan, J. Babiarz, F. Baker.

Date: February 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5127

In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network.Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments.

RFC 5128 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)

Authors: P. Srisuresh, B. Ford, D. Kegel.

Date: March 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5128

This memo documents the various methods known to be in use by applications to establish direct communication in the presence ofNetwork Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the SecurityConsiderations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP- and UDP-based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document.

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 5130 A Policy Control Mechanism in IS-IS Using Administrative Tags

Authors: S. Previdi, M. Shand, Ed., C. Martin.

Date: February 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5130

This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link StateProtocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains.

RFC 5131 A MIB Textual Convention for Language Tags

Authors: D. McWalter, Ed..

Date: December 2007

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5131

This MIB module defines a textual convention to represent BCP 47 language tags. The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation.

RFC 5132 IP Multicast MIB

Authors: D. McWalter, D. Thaler, A. Kessler.

Date: December 2007

Formats: txt html json

Obsoletes: RFC 2932

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5132

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing multicast function, independent of the specific multicast protocol(s) in use.This document obsoletes RFC 2932.

RFC 5133 Terminal Endpoint Identifier (TEI) Query Request Number Change

Authors: M. Tuexen, K. Morneault.

Date: December 2007

Formats: txt html json

Updates: RFC 4233

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5133

The Integrated Services Digital Network (ISDN) Q.921-User AdaptationLayer (IUA) Protocol, described in RFC 4233, defines the message type of Terminal Endpoint Identifier (TEI) Query Request messages as 5.However, this number is already being used by the Digital PrivateNetwork Signaling System (DPNSS)/Digital Access Signaling System 2(DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129.This document updates RFC 4233 such that the message type of TEIQuery Request messages is 8.

RFC 5134 A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards

Authors: M. Mealling.

Date: January 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5134

This document describes URN namespaces that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications.

RFC 5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)

Authors: D. Wing, T. Eckert.

Date: February 2008

Formats: txt json html

Also: BCP 0135

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5135

This document specifies requirements for a for a Network AddressTranslator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. AnIP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices.

RFC 5136 Defining Network Capacity

Authors: P. Chimento, J. Ishac.

Date: February 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5136

Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'AvailableCapacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques.

RFC 5137 ASCII Escaping of Unicode Characters

Authors: J. Klensin.

Date: February 2008

Formats: txt html json

Also: BCP 0137

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5137

There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized.

RFC 5138 A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI)

Authors: S. Cox.

Date: February 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5138

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Commission for the Management and Application ofGeoscience Information (CGI) for naming (i) persistent resources published by the CGI and (ii) resources published by organizations that wish them to be used in the context of services conforming to protocols and agreements issued by CGI. The formal NamespaceIdentifier (NID) is "cgi".

RFC 5139 Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)

Authors: M. Thomson, J. Winterbottom.

Date: February 2008

Formats: txt json html

Updates: RFC 4119

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5139

This document defines an XML format for the representation of civic location. This format is designed for use with Presence InformationData Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol(DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate.

RFC 5140 A Telephony Gateway REgistration Protocol (TGREP)

Authors: M. Bangalore, R. Kumar, J. Rosenberg, H. Salama, D.N. Shah.

Date: March 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5140

This document describes the Telephony Gateway Registration Protocol(TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP(TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony AdministrativeDomains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP.

RFC 5141 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)

Authors: J. Goodwin, H. Apel.

Date: March 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5141

This document describes a Uniform Resource Name NamespaceIdentification (URN NID) for the International Organization forStandardization (ISO). This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources).

RFC 5142 Mobility Header Home Agent Switch Message

Authors: B. Haley, V. Devarapalli, H. Deng, J. Kempf.

Date: January 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5142

This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal to a mobile node that it should acquire a new home agent.

RFC 5143 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation

Authors: A. Malis, J. Brayley, J. Shirron, L. Martini, S. Vogelsang.

Date: February 2008

Formats: txt json html

Obsoleted by: RFC 4842

Status: HISTORIC

DOI: 10.17487/RFC 5143

This document describes a historical method for encapsulatingSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Path signals for transport across packet-switched networks (PSNs).The PSNs explicitly supported by this document include MPLS and IP.Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired.

RFC 5144 A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS)

Authors: A. Newton, M. Sanz.

Date: February 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5144

This document describes a lightweight domain availability service using the Internet Registry Information Service (IRIS) framework and the data model of the IRIS Domain Registry (DREG) service.

RFC 5145 Framework for MPLS-TE to GMPLS Migration

Authors: K. Shiomoto, Ed..

Date: March 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5145

The migration from Multiprotocol Label Switching (MPLS) TrafficEngineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy.
This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy.
This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues.

RFC 5146 Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks

Authors: K. Kumaki, Ed..

Date: March 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5146

Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS(GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation ofMPLS-TE over an independently managed transport layer).
The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TELSP.
This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks.

RFC 5147 URI Fragment Identifiers for the text/plain Media Type

Authors: E. Wilde, M. Duerst.

Date: April 2008

Formats: txt json html

Updates: RFC 2046

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5147

This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust.

RFC 5148 Jitter Considerations in Mobile Ad Hoc Networks (MANETs)

Authors: T. Clausen, C. Dearlove, B. Adamson.

Date: February 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5148

This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hocNETwork (MANET) routing protocols to reduce the probability of transmission collisions.

RFC 5149 Service Selection for Mobile IPv6

Authors: J. Korhonen, U. Nilsson, V. Devarapalli.

Date: February 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5149

In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding registration procedure.

RFC 5150 Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)

Authors: A. Ayyangar, K. Kompella, JP. Vasseur, A. Farrel.

Date: February 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5150

In certain scenarios, there may be a need to combine severalGeneralized Multiprotocol Label Switching (GMPLS) Label SwitchedPaths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP.We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP.The constituent LSPs will be referred to as "LSP segments" (S-LSPs).
This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how theLSPs can be managed using the GMPLS signaling and routing protocols.
It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching.

RFC 5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions

Authors: A. Farrel, Ed., A. Ayyangar, JP. Vasseur.

Date: February 2008

Formats: txt html json

Updates: RFC 3209, RFC 3473

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5151

This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering(MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance ofLabel Switched Paths that cross domain boundaries.
For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains includeAutonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks.

RFC 5152 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)

Authors: JP. Vasseur, Ed., A. Ayyangar, Ed., R. Zhang.

Date: February 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5152

This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) MultiprotocolLabel Switching (MPLS) and Generalized MPLS (GMPLS) Label SwitchedPaths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.
Per-domain computation applies where the full path of an inter-domainTE LSP cannot be or is not determined at the ingress node of the TELSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain.

RFC 5153 IP Flow Information Export (IPFIX) Implementation Guidelines

Authors: E. Boschi, L. Mark, J. Quittek, M. Stiemerling, P. Aitken.

Date: April 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5153

The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.).

RFC 5154 IP over IEEE 802.16 Problem Statement and Goals

Authors: J. Jee, Ed., S. Madanapalli, J. Mandin.

Date: April 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5154

This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media AccessControl (MAC) for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented.

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 5156 Special-Use IPv6 Addresses

Authors: M. Blanchet.

Date: April 2008

Formats: txt json html

Obsoleted by: RFC 6890

Status: INFORMATIONAL

DOI: 10.17487/RFC 5156

This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets.It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries.

RFC 5157 IPv6 Implications for Network Scanning

Authors: T. Chown.

Date: March 2008

Formats: txt json html

Obsoleted by: RFC 7707

Status: INFORMATIONAL

DOI: 10.17487/RFC 5157

The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discoverIPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security.

RFC 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 5159 Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection

Authors: L. Dondeti, Ed., A. Jerichow.

Date: March 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5159

This document provides descriptions of Session Description Protocol(SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification.

RFC 5160 Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)

Authors: P. Levis, M. Boucadair.

Date: March 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5160

This memo analyzes provider-to-provider Quality of Service (QoS) agreements suitable for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It proposes a new concept denoted by Meta-QoS-Class (MQC). This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers. It opens up new perspectives for a QoS- enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet.

RFC 5161 The IMAP ENABLE Extension

Authors: A. Gulbrandsen, Ed., A. Melnikov, Ed..

Date: March 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5161

Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports.

RFC 5162 IMAP4 Extensions for Quick Mailbox Resynchronization

Authors: A. Melnikov, D. Cridland, C. Wilson.

Date: March 2008

Formats: txt json html

Obsoleted by: RFC 7162

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5162

This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged).

RFC 5163 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)

Authors: G. Fairhurst, B. Collini-Nocker.

Date: April 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5163

This document describes a set of Extension Headers for theUnidirectional Lightweight Encapsulation (ULE), RFC 4326.
The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic StreamEncapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications.

RFC 5164 Mobility Services Transport: Problem Statement

Authors: T. Melia, Ed..

Date: March 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5164

There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE802.21. Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF. This document presents a problem statement for this core problem.

RFC 5165 A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC)

Authors: C. Reed.

Date: April 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5165

This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal NamespaceIDentifier (NID) is "ogc".

RFC 5166 Metrics for the Evaluation of Congestion Control Mechanisms

Authors: S. Floyd, Ed..

Date: March 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5166

This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet.These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.
This document is a product of the Transport Modeling Research Group(TMRG), and has received detailed feedback from many members of theResearch Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or theIETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade- offs between a range of metrics, rather than in terms of optimizing for a single metric.

RFC 5167 Media Server Control Protocol Requirements

Authors: M. Dolly, R. Even.

Date: March 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5167

This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.
This document presents the requirements for a Media Server ControlProtocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, InteractiveVoice Response, and conferencing media services.

RFC 5168 XML Schema for Media Control

Authors: O. Levin, R. Even, P. Hagendorf.

Date: March 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5168

This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed byMicrosoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in SessionInitiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel.

RFC 5169 Handover Key Management and Re-Authentication Problem Statement

Authors: T. Clancy, M. Nakhjiri, V. Narayanan, L. Dondeti.

Date: March 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5169

This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol(EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover.

RFC 5170 Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes

Authors: V. Roca, C. Neumann, D. Furodet.

Date: June 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5170

This document describes two Fully-Specified Forward Error Correction(FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPCTriangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). These systematic FEC codes belong to the well- known class of "Low Density Parity Check" codes, and are large blockFEC codes in the sense of RFC 3453.

RFC 5171 Cisco Systems UniDirectional Link Detection (UDLD) Protocol

Authors: M. Foschiano.

Date: April 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5171

This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms.
This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization.

RFC 5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol

Authors: S. Varada, Ed..

Date: March 2008

Formats: txt json html

Obsoletes: RFC 2472

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5172

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.
The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.
This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP.

RFC 5173 Sieve Email Filtering: Body Extension

Authors: J. Degener, P. Guenther.

Date: April 2008

Formats: txt json html

Updates: RFC 5229

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5173

This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message.

RFC 5174 A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU)

Authors: J-P. Evain.

Date: May 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5174

This document describes a Uniform Resource Name (URN) namespace for the European Broadcasting Union (EBU) for naming persistent resources defined within EBU technical documentation and Internet resources.Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XMLDocument Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the EBU.

RFC 5175 IPv6 Router Advertisement Flags Option

Authors: B. Haberman, Ed., R. Hinden.

Date: March 2008

Formats: txt html json

Obsoletes: RFC 5075

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5175

The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the number of flag bits available.

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 5178 Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type

Authors: N. Williams, A. Melnikov.

Date: May 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5178

This document describes domain-name-based service principal names and the corresponding name type for the Generic Security ServiceApplication Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.
Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names.

RFC 5179 Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism

Authors: N. Williams.

Date: May 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5179

This document describes the mapping of Generic Security ServiceApplication Program Interface (GSS-API) domain-name-based service principal names onto Kerberos V principal names.

RFC 5180 IPv6 Benchmarking Methodology for Network Interconnect Devices

Authors: C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin.

Date: May 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5180

The benchmarking methodologies defined in RFC 2544 are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document.

RFC 5181 IPv6 Deployment Scenarios in 802.16 Networks

Authors: M-K. Shin, Ed., Y-H. Han, S-E. Kim, D. Premec.

Date: May 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5181

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies.

RFC 5182 IMAP Extension for Referencing the Last SEARCH Result

Authors: A. Melnikov.

Date: March 2008

Formats: txt json html

Updates: RFC 3501

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5182

Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.
This can be achieved using standard IMAP operations described in RFC3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server.The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.
This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID)SEARCH) command as an input to any subsequent command.

RFC 5183 Sieve Email Filtering: Environment Extension

Authors: N. Freed.

Date: May 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5183

This document describes the "environment" extension to the Sieve email filtering language. The "environment" extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message.

RFC 5184 Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover

Authors: F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, K. Mitani.

Date: May 2008

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5184

This document proposes unified Layer 2 (L2) abstractions for Layer 3(L3)-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers.This document defines nine kinds of L2 abstractions in the form of"primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives. This document is a product of theIP Mobility Optimizations (MobOpts) Research Group.

RFC 5185 OSPF Multi-Area Adjacency

Authors: S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal.

Date: May 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5185

This document describes an extension to the Open Shortest Path First(OSPF) protocol to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra- area path in each of the corresponding areas sharing the same link.

RFC 5186 Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction

Authors: B. Haberman, J. Martin.

Date: May 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5186

The definitions of the Internet Group Management Protocol Version 3(IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information. This document describes how multicast routing protocols will interact with these source-filtering group management protocols.

RFC 5187 OSPFv3 Graceful Restart

Authors: P. Pillay-Esnault, A. Lindem.

Date: June 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5187

This document describes the OSPFv3 graceful restart. The OSPFv3 graceful restart is identical to that of OSPFv2 except for the differences described in this document. These differences include the format of the grace Link State Advertisements (LSAs) and other considerations.

RFC 5188 RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec

Authors: H. Desineni, Q. Xie.

Date: February 2008

Formats: txt html json

Updates: RFC 4788

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5188

This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Wideband Codec(EVRC-WB) and updates the media type registrations for EVRC-B codec.Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport ofEVRC-WB speech data in storage mode applications such as email.

RFC 5189 Middlebox Communication (MIDCOM) Protocol Semantics

Authors: M. Stiemerling, J. Quittek, T. Taylor.

Date: March 2008

Formats: txt html json

Obsoletes: RFC 3989

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5189

This document specifies semantics for a Middlebox Communication(MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs).The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This document obsoletes RFC 3989.

RFC 5190 Definitions of Managed Objects for Middlebox Communication

Authors: J. Quittek, M. Stiemerling, P. Srisuresh.

Date: March 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5190

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices.The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189.

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 5192 DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents

Authors: L. Morand, A. Yegin, S. Kumar, S. Madanapalli.

Date: May 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5192

This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more PANA (Protocol for carrying Authentication for Network Access) Authentication Agents(PAAs). This is one of the methods that a PANA Client (PaC) can use to locate PAAs.

RFC 5193 Protocol for Carrying Authentication for Network Access (PANA) Framework

Authors: P. Jayaraman, R. Lopez, Y. Ohba, Ed., M. Parthasarathy, A. Yegin.

Date: May 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5193

This document defines the general Protocol for CarryingAuthentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments.

RFC 5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)

Authors: A. van Wijk, Ed., G. Gybels, Ed..

Date: June 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5194

This document lists the essential requirements for real-time Text- over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the PublicSwitched Telephone Network (PSTN) and other networks.

RFC 5195 BGP-Based Auto-Discovery for Layer-1 VPNs

Authors: H. Ould-Brahim, D. Fedyk, Y. Rekhter.

Date: June 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5195

The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached toCustomer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections.One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port.

RFC 5196 Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)

Authors: M. Lonnfors, K. Kiss.

Date: September 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5196

Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP UserAgent capabilities.

RFC 5197 On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions

Authors: S. Fries, D. Ignjatic.

Date: June 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5197

Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for real-time applications. In particular, it has been defined focusing on the support of the Secure Real-time TransportProtocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements.
This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session DescriptionProtocol (SDP) answer, forking, and shared key conferencing.

RFC 5198 Unicode Format for Network Interchange

Authors: J. Klensin, M. Padlipsky.

Date: March 2008

Formats: txt html json

Obsoletes: RFC 0698

Updates: RFC 0854

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5198

The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences.

RFC 5201 Host Identity Protocol

Authors: R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson.

Date: April 2008

Formats: txt html json

Obsoleted by: RFC 7401

Updated by: RFC 6253

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5201

This memo specifies the details of the Host Identity Protocol (HIP).HIP allows consenting hosts to securely establish and maintain sharedIP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP.

RFC 5202 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)

Authors: P. Jokela, R. Moskowitz, P. Nikander.

Date: April 2008

Formats: txt json html

Obsoleted by: RFC 7402

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5202

This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with theHost Identity Protocol (HIP).

RFC 5203 Host Identity Protocol (HIP) Registration Extension

Authors: J. Laganier, T. Koponen, L. Eggert.

Date: April 2008

Formats: txt json html

Obsoleted by: RFC 8003

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5203

This document specifies a registration mechanism for the HostIdentity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes.

RFC 5204 Host Identity Protocol (HIP) Rendezvous Extension

Authors: J. Laganier, L. Eggert.

Date: April 2008

Formats: txt html json

Obsoleted by: RFC 8004

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5204

This document defines a rendezvous extension for the Host IdentityProtocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile.

RFC 5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions

Authors: P. Nikander, J. Laganier.

Date: April 2008

Formats: txt html json

Obsoleted by: RFC 8005

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5205

This document specifies a new resource record (RR) for the DomainName System (DNS), and how to use it with the Host Identity Protocol(HIP). This RR allows a HIP node to store in the DNS its HostIdentity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs).

RFC 5206 End-Host Mobility and Multihoming with the Host Identity Protocol

Authors: P. Nikander, T. Henderson, Ed., C. Vogt, J. Arkko.

Date: April 2008

Formats: txt json html

Obsoleted by: RFC 8046

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5206

This document defines mobility and multihoming extensions to the HostIdentity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study.

RFC 5207 NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication

Authors: M. Stiemerling, J. Quittek, L. Eggert.

Date: April 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5207

The Host Identity Protocol (HIP) changes the way in which twoInternet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These"middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group.

RFC 5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2

Authors: B. Kaliski.

Date: May 2008

Formats: txt html json

Obsoleted by: RFC 5958

Status: INFORMATIONAL

DOI: 10.17487/RFC 5208

This document represents a republication of PKCS #8 v1.2 from RSALaboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.
This document describes a syntax for private-key information.

RFC 5209 Network Endpoint Assessment (NEA): Overview and Requirements

Authors: P. Sangster, H. Khosravi, M. Mani, K. Narayan, J. Tardo.

Date: June 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5209

This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network EndpointAssessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced.

RFC 5210 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience

Authors: J. Wu, J. Bi, X. Li, G. Ren, K. Xu, M. Williams.

Date: June 2008

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5210

Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet withIP source address validation, a prototype implementation of the IPSource Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation.

RFC 5211 An Internet Transition Plan

Authors: J. Curran.

Date: July 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5211

This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantlyIPv6-based connectivity model.

RFC 5212 Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)

Authors: K. Shiomoto, D. Papadimitriou, JL. Le Roux, M. Vigoureux, D. Brungard.

Date: July 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5212

Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extendingMPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.
In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi- layer networks and lists a set of functional requirements.

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 5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

Authors: F. Templin, T. Gleeson, D. Thaler.

Date: March 2008

Formats: txt html json

Obsoletes: RFC 4214

Status: INFORMATIONAL

DOI: 10.17487/RFC 5214

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views theIPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access(NBMA) model.

RFC 5215 RTP Payload Format for Vorbis Encoded Audio

Authors: L. Barbato.

Date: August 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5215

This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for rawVorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.
Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session DescriptionProtocol (SDP).

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 5217 Memorandum for Multi-Domain Public Key Infrastructure Interoperability

Authors: M. Shimaoka, Ed., N. Hastings, R. Nielsen.

Date: July 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5217

The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public KeyInfrastructure (PKI) domain for interoperability of multi-domainPublic Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships betweenCertification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi- domain PKI.

RFC 5218 What Makes for a Successful Protocol?

Authors: D. Thaler, B. Aboba.

Date: July 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5218

The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success.Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work.

RFC 5219 A More Loss-Tolerant RTP Payload Format for MP3 Audio

Authors: R. Finlayson.

Date: February 2008

Formats: txt html json

Obsoletes: RFC 3119

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5219

This document describes an RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layerIII audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices.

RFC 5220 Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules

Authors: A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama.

Date: July 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5220

A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes.

RFC 5221 Requirements for Address Selection Mechanisms

Authors: A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama.

Date: July 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5221

There are some problematic cases when using the default address selection mechanism that RFC 3484 defines. This document describes additional requirements that operate with RFC 3484 to solve the problems.

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 5223 Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)

Authors: H. Schulzrinne, J. Polk, H. Tschofenig.

Date: August 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5223

The Location-to-Service Translation (LoST) Protocol describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform ResourceLocators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.
This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP).

RFC 5224 Diameter Policy Processing Application

Authors: M. Brenner.

Date: March 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5224

This document describes the need for a new IANA Diameter Command Code to be used in a vendor-specific new application for invocation ofPolicy Processing (Policy Evaluation, or Evaluation and Enforcement).This application is needed as one of the implementations of the OpenMobile Alliance (OMA) Policy Evaluation, Enforcement and Management(PEEM) enabler, namely for the PEM-1 interface used to send a request/response for Policy Processing.

RFC 5225 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite

Authors: G. Pelletier, K. Sandlund.

Date: April 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5225

This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol,User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (UserDatagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP(Encapsulating Security Payload) headers.
This specification defines a second version of the profiles found inRFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them.
The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation.

RFC 5226 Guidelines for Writing an IANA Considerations Section in RFCs

Authors: T. Narten, H. Alvestrand.

Date: May 2008

Formats: txt json html

Obsoletes: RFC 2434

Obsoleted by: RFC 8126

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5226

Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned NumbersAuthority (IANA).
In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. IfIANA is expected to play a role in the management of a namespace,IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.
This document obsoletes RFC 2434.

RFC 5227 IPv4 Address Conflict Detection

Authors: S. Cheshire.

Date: July 2008

Formats: txt json html

Updates: RFC 0826

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5227

When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem.

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 5231 Sieve Email Filtering: Relational Extension

Authors: W. Segmuller, B. Leiba.

Date: January 2008

Formats: txt html json

Obsoletes: RFC 3431

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5231

This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators.In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields.
This document obsoletes RFC 3431.

RFC 5232 Sieve Email Filtering: Imap4flags Extension

Authors: A. Melnikov.

Date: January 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5232

Recent discussions have shown that it is desirable to set differentIMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a MailDelivery Agent.
This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords.

RFC 5233 Sieve Email Filtering: Subaddress Extension

Authors: K. Murchison.

Date: January 2008

Formats: txt json html

Obsoletes: RFC 3598

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5233

On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses.This document defines an extension to the Sieve Email FilteringLanguage that allows users to compare against the user and detail sub-parts of an address.

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 5235 Sieve Email Filtering: Spamtest and Virustest Extensions

Authors: C. Daboo.

Date: January 2008

Formats: txt html json

Obsoletes: RFC 3685

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5235

The Sieve email filtering language "spamtest", "spamtestplus", and"virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric "scores". It is the responsibility of the underlying Sieve implementation to do the actual checks that result in proper input to the tests.

RFC 5236 Improved Packet Reordering Metrics

Authors: A. Jayasumana, N. Piratla, T. Banka, A. Bare, R. Whitner.

Date: June 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5236

This document presents two improved metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density(RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering.
These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication.

RFC 5237 IANA Allocation Guidelines for the Protocol Field

Authors: J. Arkko, S. Bradner.

Date: February 2008

Formats: txt json html

Updates: RFC 2780

Also: BCP 0037

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5237

This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6.

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 5239 A Framework for Centralized Conferencing

Authors: M. Barnes, C. Boulton, O. Levin.

Date: June 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5239

This document defines the framework for Centralized Conferencing.The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part(ISUP), to exchange media in a centralized unicast conference. TheCentralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems.

RFC 5240 Protocol Independent Multicast (PIM) Bootstrap Router MIB

Authors: B. Joshi, R. Bijlani.

Date: June 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5240

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM (ProtocolIndependent Multicast).

RFC 5241 Naming Rights in IETF Protocols

Authors: A. Falk, S. Bradner.

Date: 1 April 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5241

This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process.

RFC 5242 A Generalized Unified Character Code: Western European and CJK Sections

Authors: J. Klensin, H. Alvestrand.

Date: 1 April 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5242

Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters. It is not a complete specification of that character set.

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 5244 Definition of Events for Channel-Oriented Telephony Signalling

Authors: H. Schulzrinne, T. Taylor.

Date: June 2008

Formats: txt json html

Updates: RFC 4733

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5244

This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833. As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833.

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 5248 A Registry for SMTP Enhanced Mail System Status Codes

Authors: T. Hansen, J. Klensin.

Date: June 2008

Formats: txt json html

Updates: RFC 3463, RFC 4468, RFC 4954

Also: BCP 0138

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5248

The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes.While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry.

RFC 5249 Templates for Internet-Drafts Containing MIB Modules

Authors: D. Harrington, Ed..

Date: July 2008

Formats: txt json html

Also: BCP 0139

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5249

This memo references three annotated templates for IETF documents that contain the definition of MIB modules. It is intended to reduce the work of the editors of such documents, making these documents more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication.

RFC 5250 The OSPF Opaque LSA Option

Authors: L. Berger, I. Bryskin, A. Zinin, R. Coltun.

Date: July 2008

Formats: txt json html

Obsoletes: RFC 2370

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5250

This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs.Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute OpaqueLSAs to all or some limited portion of the OSPF topology.
This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area.

RFC 5251 Layer 1 VPN Basic Mode

Authors: D. Fedyk, Ed., Y. Rekhter, Ed., D. Papadimitriou, R. Rabbat, L. Berger.

Date: July 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5251

This document describes the Basic Mode of Layer 1 VPNs (L1VPNs).L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN BasicMode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology.This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM.

RFC 5252 OSPF-Based Layer 1 VPN Auto-Discovery

Authors: I. Bryskin, L. Berger.

Date: July 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5252

This document defines an Open Shortest Path First (OSPF) based Layer1 Virtual Private Network (L1VPN) auto-discovery mechanism. This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about the existence of each other, and attributes of configured customer edge (CE) links and their associations withL1VPNs. This document builds on the L1VPN framework and requirements and provides a L1VPN basic mode auto-discovery mechanism.

RFC 5253 Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode

Authors: T. Takeda, Ed..

Date: July 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5253

This document provides an applicability statement on the use ofGeneralized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks(L1VPNs).
L1VPNs provide customer services and connectivity at Layer 1 overLayer 1 networks. The operation of L1VPNs is divided into the BasicMode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic ModeL1VPN.

RFC 5254 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)

Authors: N. Bitar, Ed., M. Bocci, Ed., L. Martini, Ed..

Date: October 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5254

This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains.These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains.

RFC 5255 Internet Message Access Protocol Internationalization

Authors: C. Newman, A. Gulbrandsen, A. Melnikov.

Date: June 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5255

Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME).This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread.

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 5257 Internet Message Access Protocol - ANNOTATE Extension

Authors: C. Daboo, R. Gellens.

Date: June 2008

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5257

The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.
Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. TheIETF solicits implementations and implementation reports in order to make further progress.
Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension.

RFC 5258 Internet Message Access Protocol version 4 - LIST Command Extensions

Authors: B. Leiba, A. Melnikov.

Date: June 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5258

IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands.

RFC 5259 Internet Message Access Protocol - CONVERT Extension

Authors: A. Melnikov, Ed., P. Coates, Ed..

Date: July 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5259

CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings.

RFC 5260 Sieve Email Filtering: Date and Index Extensions

Authors: N. Freed.

Date: July 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5260

This document describes the "date" and "index" extensions to theSieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated.

RFC 5261 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors

Authors: J. Urpalainen.

Date: September 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5261

Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document.In addition to them, with basic <add&rt;, <replace&rt;, and <remove&rt; directives a set of patches can then be applied to update an existingXML document.

RFC 5262 Presence Information Data Format (PIDF) Extension for Partial Presence

Authors: M. Lonnfors, E. Leppanen, H. Khartabil, J. Urpalainen.

Date: September 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5262

The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information.

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 5264 Publication of Partial Presence Information

Authors: A. Niemi, M. Lonnfors, E. Leppanen.

Date: September 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5264

The Session Initiation Protocol (SIP) Extension for Event StatePublication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using thePresence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information.

RFC 5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways

Authors: S. Vaarala, E. Klovning.

Date: June 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5265

This document outlines a solution for the Mobile IPv4 (MIPv4) andIPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 andIPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely.

RFC 5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)

Authors: V. Devarapalli, P. Eronen.

Date: June 2008

Formats: txt html json

Also: BCP 0136

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5266

Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using MobileIPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility.

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 5268 Mobile IPv6 Fast Handovers

Authors: R. Koodli, Ed..

Date: June 2008

Formats: txt json html

Obsoletes: RFC 4068

Obsoleted by: RFC 5568

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5268

Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This"handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, andBinding Update, is often unacceptable to real-time traffic such asVoice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency.

RFC 5269 Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)

Authors: J. Kempf, R. Koodli.

Date: June 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5269

Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a MobileNode in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the MobileNode is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as forSEND (RFC 3971). The Mobile Node sends the public key to the AccessRouter. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use theRouter Solicitation for Proxy Advertisement and Proxy RouterAdvertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node.This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key.

RFC 5270 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks

Authors: H. Jang, J. Jee, Y. Han, S. Park, J. Cha.

Date: June 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5270

This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the MobileIPv6 fast handover procedures efficiently.

RFC 5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks

Authors: H. Yokota, G. Dommety.

Date: June 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5271

Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a newCare-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover.

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 5275 CMS Symmetric Key Management and Distribution

Authors: S. Turner.

Date: June 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5275

This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses theCryptographic Message Syntax (CMS) protocol and CertificateManagement over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose InternetMail Extensions (S/MIME) Mail List Agents (MLAs).

RFC 5276 Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records

Authors: C. Wallace.

Date: August 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5276

The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs).

RFC 5277 NETCONF Event Notifications

Authors: S. Chisholm, H. Trevino.

Date: July 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5277

This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol(NETCONF). This is an optional capability built on top of the baseNETCONF definition. This document defines the capabilities and operations necessary to support this service.

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 5279 A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)

Authors: A. Monrad, S. Loreto.

Date: July 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5279

This document describes the Namespace Identifier (NID) for UniformResource Namespace (URN) resources published by the 3rd GenerationPartnership Project (3GPP). 3GPP defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the 3GPP Support Team.

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 5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol

Authors: D. Black, D. McGrew.

Date: August 2008

Formats: txt html json

Updates: RFC 4306

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5282

An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet KeyExchange version 2 (IKEv2) protocol.
The use of two specific authenticated encryption algorithms with theIKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AESGCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload.

RFC 5283 LDP Extension for Inter-Area Label Switched Paths (LSPs)

Authors: B. Decraene, JL. Le Roux, I. Minei.

Date: July 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5283

To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label MappingProcedure for the Label Distribution Protocol (LDP).
This procedure allows the use of a label if the ForwardingEquivalence Class (FEC) Element matches an entry in the RoutingInformation Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match.

RFC 5284 User-Defined Errors for RSVP

Authors: G. Swallow, A. Farrel.

Date: August 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5284

The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.
This document defines a USER_ERROR_SPEC to be used in addition to theERROR_SPEC to carry additional user information related to errors.

RFC 5285 A General Mechanism for RTP Header Extensions

Authors: D. Singer, H. Desineni.

Date: July 2008

Formats: txt json html

Obsoleted by: RFC 8285

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5285

This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in eachRTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session.

RFC 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 5287 Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks

Authors: A. Vainshtein, Y(J). Stein.

Date: August 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5287

This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks.

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 5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)

Authors: E. Rescorla.

Date: August 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5289

RFC 4492 describes elliptic curve cipher suites for Transport LayerSecurity (TLS). However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm. This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms. Eight use Hashed Message Authentication Code (HMAC) withSHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM).

RFC 5290 Comments on the Usefulness of Simple Best-Effort Traffic

Authors: S. Floyd, M. Allman.

Date: July 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5290

This document presents some observations on "simple best-effort traffic", defined loosely for the purposes of this document asInternet traffic that is not covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like. One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping.While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as *adjuncts* to simple best- effort traffic, not as *replacements* of simple best-effort traffic.A second observation is that for simple best-effort traffic, some form of rough flow-rate fairness is a useful goal for resource allocation, where "flow-rate fairness" is defined by the goal of equal flow rates for different flows over the same path.

RFC 5291 Outbound Route Filtering Capability for BGP-4

Authors: E. Chen, Y. Rekhter.

Date: August 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5291

This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that the peer would use to constrain/filter its outbound routing updates to the speaker.

RFC 5292 Address-Prefix-Based Outbound Route Filter for BGP-4

Authors: E. Chen, S. Sangli.

Date: August 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5292

This document defines a new Outbound Router Filter (ORF) type forBGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address-prefix-based route filtering. This ORF-type supports prefix-length- or range-based matching, wild-card-based address prefix matching, as well as the exact address prefix matching for address families.

RFC 5293 Sieve Email Filtering: Editheader Extension

Authors: J. Degener, P. Guenther.

Date: August 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5293

This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields.

RFC 5294 Host Threats to Protocol Independent Multicast (PIM)

Authors: P. Savola, J. Lingard.

Date: August 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5294

This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol IndependentMulticast (PIM) threats specific to router interfaces connecting hosts.

RFC 5295 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)

Authors: J. Salowey, L. Dondeti, V. Narayanan, M. Nakhjiri.

Date: August 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5295

The Extensible Authentication Protocol (EAP) defined the ExtendedMaster Session Key (EMSK) generation, but reserved it for unspecified future uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains.

RFC 5296 EAP Extensions for EAP Re-authentication Protocol (ERP)

Authors: V. Narayanan, L. Dondeti.

Date: August 2008

Formats: txt html json

Obsoleted by: RFC 6696

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5296

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting.

RFC 5297 Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)

Authors: D. Harkins.

Date: October 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5297

This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption.

RFC 5298 Analysis of Inter-Domain Label Switched Path (LSP) Recovery

Authors: T. Takeda, Ed., A. Farrel, Ed., Y. Ikejiri, JP. Vasseur.

Date: August 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5298

Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments.
Various schemes and processes have been developed to establish LabelSwitched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain MultiprotocolLabel Switching Traffic Engineering".
This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse TrafficEngineering (TE) LSPs in multi-domain networks.

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 5302 Domain-Wide Prefix Distribution with Two-Level IS-IS

Authors: T. Li, H. Smit, T. Przygienda.

Date: October 2008

Formats: txt html json

Obsoletes: RFC 2966

Updates: RFC 1195

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5302

This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966.
This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 IntermediateSystems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form.The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain.

RFC 5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies

Authors: D. Katz, R. Saluja, D. Eastlake 3rd.

Date: October 2008

Formats: txt html json

Obsoletes: RFC 3373

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5303

The IS-IS routing protocol (Intermediate System to IntermediateSystem, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media.This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.
Additionally, the extension allows the robust operation of more than256 point-to-point links on a single router.
This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors.

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 5306 Restart Signaling for IS-IS

Authors: M. Shand, L. Ginsberg.

Date: October 2008

Formats: txt html json

Obsoletes: RFC 3847

Obsoleted by: RFC 8706

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5306

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.
This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol DataUnit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 3847.

RFC 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 5309 Point-to-Point Operation over LAN in Link State Routing Protocols

Authors: N. Shen, Ed., A. Zinin, Ed..

Date: October 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5309

The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing.

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 5311 Simplified Extension of Link State PDU (LSP) Space for IS-IS

Authors: D. McPherson, Ed., L. Ginsberg, S. Previdi, M. Shand.

Date: February 2009

Formats: txt json html

Obsoletes: RFC 3786

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5311

This document describes a simplified method for extending the LinkState PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC3786.

RFC 5316 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering

Authors: M. Chen, R. Zhang, X. Duan.

Date: December 2008

Formats: txt html json

Obsoleted by: RFC 9346

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5316

This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems(ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS is proposed or defined in this document.

RFC 5317 Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile

Authors: S. Bryant, Ed., L. Andersson, Ed..

Date: February 2009

Formats: txt pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5317

This RFC archives the report of the IETF - ITU-T Joint Working Team(JWT) on the application of MPLS to transport networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extendIETF MPLS forwarding, OAM (Operations, Administration, andManagement), survivability, network management and control plane protocols to meet those requirements through the IETF StandardsProcess. This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides).

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 5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL)

Authors: F. Templin, Ed..

Date: February 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5320

For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverseMaximum Transmission Units (MTUs). This document specifies aSubnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies.

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 5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH

Authors: J. Reschke, Ed., S. Reddy, J. Davis, A. Babich.

Date: November 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5323

This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria.

RFC 5324 MIB for Fibre-Channel Security Protocols (FC-SP)

Authors: C. DeSanti, F. Maino, K. McCloghrie.

Date: September 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5324

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 information related to FC-SP, the Security Protocols defined for Fibre Channel.

RFC 5325 Licklider Transmission Protocol - Motivation

Authors: S. Burleigh, M. Ramadas, S. Farrell.

Date: September 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5325

This document describes the motivation for the development of theLicklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.
In an Interplanetary Internet setting deploying the Bundle protocol,LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does AutomaticRepeat reQuest (ARQ) of data transmissions by soliciting selective- acknowledgment reception reports. It is stateful and has no negotiation or handshakes.
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.

RFC 5326 Licklider Transmission Protocol - Specification

Authors: M. Ramadas, S. Burleigh, S. Farrell.

Date: September 2008

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5326

This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but it has applications in other environments as well.
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.

RFC 5327 Licklider Transmission Protocol - Security Extensions

Authors: S. Farrell, M. Ramadas, S. Burleigh.

Date: September 2008

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5327

The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency(RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.

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 5329 Traffic Engineering Extensions to OSPF Version 3

Authors: K. Ishiguro, V. Manral, A. Davey, A. Lindem, Ed..

Date: September 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5329

This document describes extensions to OSPFv3 to support intra-areaTraffic Engineering (TE). This document extends OSPFv2 TE to handleIPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks.

RFC 5330 A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link

Authors: JP. Vasseur, Ed., M. Meyer, K. Kumaki, A. Bonda.

Date: October 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5330

Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System toIntermediate System (IS-IS) in the context of Multiprotocol LabelSwitching (MPLS) Traffic Engineering (TE), in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on. By making statistical assumptions about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwidth(referred to as "unconstrained TE LSP" in this document), algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSPs signalled across a link.

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 5332 MPLS Multicast Encapsulations

Authors: T. Eckert, E. Rosen, Ed., R. Aggarwal, Y. Rekhter.

Date: August 2008

Formats: txt html json

Updates: RFC 3032, RFC 4023

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5332

RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the"multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label".
RFC 3032 does not specify the destination address to be placed in the"MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification.
This document updates RFC 3032 and RFC 4023.

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 5335 Internationalized Email Headers

Authors: A. Yang, Ed..

Date: September 2008

Formats: txt json html

Obsoleted by: RFC 6532

Updates: RFC 2045, RFC 2822

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5335

Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant ofInternet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field.This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements.

RFC 5336 SMTP Extension for Internationalized Email Addresses

Authors: J. Yao, Ed., W. Mao, Ed..

Date: September 2008

Formats: txt html json

Obsoleted by: RFC 6531

Updates: RFC 2821, RFC 2822, RFC 4952

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5336

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952.

RFC 5337 Internationalized Delivery Status and Disposition Notifications

Authors: C. Newman, A. Melnikov, Ed..

Date: September 2008

Formats: txt html json

Obsoleted by: RFC 6533

Updates: RFC 3461, RFC 3462, RFC 3464, RFC 3798

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5337

Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.
This document experimentally extends RFC 3461, RFC 3464, and RFC3798.

RFC 5338 Using the Host Identity Protocol with Legacy Applications

Authors: T. Henderson, P. Nikander, M. Komu.

Date: September 2008

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5338

This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names.From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to usingHIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP.

RFC 5339 Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)

Authors: JL. Le Roux, Ed., D. Papadimitriou, Ed..

Date: September 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5339

This document provides an evaluation of Generalized MultiprotocolLabel Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLNs) and Multi-RegionNetworks (MRNs). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions.

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 5341 The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry

Authors: C. Jennings, V. Gurbani.

Date: September 2008

Formats: txt html json

Updates: RFC 3966

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5341

This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups.

RFC 5342 IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters

Authors: D. Eastlake 3rd.

Date: September 2008

Formats: txt json html

Obsoleted by: RFC 7042

Updates: RFC 2153

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5342

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters inIETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier).

RFC 5343 Simple Network Management Protocol (SNMP) Context EngineID Discovery

Authors: J. Schoenwaelder.

Date: September 2008

Formats: txt json html

Updates: RFC 3411

Also: STD 0078

Status: INTERNET STANDARD

DOI: 10.17487/RFC 5343

The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.
This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.
This document updates RFC 3411.

RFC 5344 Presence and Instant Messaging Peering Use Cases

Authors: A. Houri, E. Aoki, S. Parameswar.

Date: October 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5344

This document describes several use cases of peering of non-VoIP(Voice over IP) services between two or more Service Providers.These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM).

RFC 5345 Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats

Authors: J. Schoenwaelder.

Date: October 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5345

The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements.Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.
This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.
This document was produced within the IRTF's Network ManagementResearch Group (NMRG), and it represents the consensus of all of the active contributors to this group.

RFC 5346 Operational Requirements for ENUM-Based Softswitch Use

Authors: J. Lim, W. Kim, C. Park, L. Conroy.

Date: October 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5346

This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National InternetDevelopment Agency of Korea (NIDA) in 2006.
These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls.

RFC 5347 Media Gateway Control Protocol Fax Package

Authors: F. Andreasen, D. Hancock.

Date: October 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5347

This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-TRecommendation T.38 for fax relay under the control of the CallAgent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call withoutCall Agent involvement.

RFC 5348 TCP Friendly Rate Control (TFRC): Protocol Specification

Authors: S. Floyd, M. Handley, J. Padhye, J. Widmer.

Date: September 2008

Formats: txt html json

Obsoletes: RFC 3448

Updates: RFC 4342

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5348

This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.
This document obsoletes RFC 3448 and updates RFC 4342.

RFC 5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)

Authors: L. Zhu, K. Jaganathan, K. Lauter.

Date: September 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5349

This document describes the use of Elliptic Curve certificates,Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman(ECDH) key agreement within the framework of PKINIT -- the KerberosVersion 5 extension that provides for the use of public key cryptography.

RFC 5350 IANA Considerations for the IPv4 and IPv6 Router Alert Options

Authors: J. Manner, A. McDonald.

Date: September 2008

Formats: txt html json

Updates: RFC 2113, RFC 3175

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5350

This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values.

RFC 5351 An Overview of Reliable Server Pooling Protocols

Authors: P. Lei, L. Ong, M. Tuexen, T. Dreibholz.

Date: September 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5351

The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in theReliable Server Pooling suite.

RFC 5352 Aggregate Server Access Protocol (ASAP)

Authors: R. Stewart, Q. Xie, M. Stillman, M. Tuexen.

Date: September 2008

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5352

Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.
In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.
ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol(SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.
The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service.

RFC 5353 Endpoint Handlespace Redundancy Protocol (ENRP)

Authors: Q. Xie, R. Stewart, M. Stillman, M. Tuexen, A. Silverton.

Date: September 2008

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5353

The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling(RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information.

RFC 5354 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters

Authors: R. Stewart, Q. Xie, M. Stillman, M. Tuexen.

Date: September 2008

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5354

This document details the parameters of the Aggregate Server AccessProtocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture.

RFC 5355 Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats

Authors: M. Stillman, Ed., R. Gopal, E. Guttman, S. Sengodan, M. Holdrege.

Date: September 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5355

Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to theRSerPool architecture and presents requirements for security to thwart these threats.

RFC 5356 Reliable Server Pooling Policies

Authors: T. Dreibholz, M. Tuexen.

Date: September 2008

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5356

This document describes server pool policies for Reliable ServerPooling (RSerPool) including considerations for implementing them atEndpoint Handlespace Redundancy Protocol (ENRP) servers and pool users.

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 5358 Preventing Use of Recursive Nameservers in Reflector Attacks

Authors: J. Damas, F. Neves.

Date: October 2008

Formats: txt html json

Also: BCP 0140

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5358

This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack.

RFC 5359 Session Initiation Protocol Service Examples

Authors: A. Johnston, Ed., R. Sparks, C. Cunningham, S. Donovan, K. Summers.

Date: October 2008

Formats: txt html json

Also: BCP 0144

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5359

This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private BranchExchange) features. Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment.

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 5361 A Document Format for Requesting Consent

Authors: G. Camarillo.

Date: October 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5361

This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation.

RFC 5362 The Session Initiation Protocol (SIP) Pending Additions Event Package

Authors: G. Camarillo.

Date: October 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5362

This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list.

RFC 5363 Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services

Authors: G. Camarillo, A.B. Roach.

Date: October 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5363

This document describes the need for SIP URI-list services and provides requirements for their invocation. Additionally, it defines a framework for SIP URI-list services, which includes security considerations applicable to these services.

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 5365 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)

Authors: M. Garcia-Martin, G. Camarillo.

Date: October 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5365

This document specifies a mechanism that allows a SIP User AgentClient (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service.The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends aMESSAGE request including the payload to each of the URIs included in the list.

RFC 5366 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)

Authors: G. Camarillo, A. Johnston.

Date: October 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5366

This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a UserAgent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list.

RFC 5367 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)

Authors: G. Camarillo, A.B. Roach, O. Levin.

Date: October 2008

Formats: txt json html

Updates: RFC 3265

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5367

This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a singleSUBSCRIBE dialog.

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 5369 Framework for Transcoding with the Session Initiation Protocol (SIP)

Authors: G. Camarillo.

Date: October 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5369

This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals.

RFC 5370 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model

Authors: G. Camarillo.

Date: October 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5370

This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals.

RFC 5371 RTP Payload Format for JPEG 2000 Video Streams

Authors: S. Futemma, E. Itakura, A. Leung.

Date: October 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5371

This memo describes an RTP payload format for the ISO/IECInternational Standard 15444-1 | ITU-T Rec. T.800, better known asJPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways.The JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images.

RFC 5372 Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery

Authors: A. Leung, S. Futemma, E. Itakura.

Date: October 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5372

This memo describes extended uses for the payload header in "RTPPayload Format for JPEG 2000 Video Streams" as specified in RFC 5371, for better support of JPEG 2000 features such as scalability and main header recovery.
This memo must be accompanied with a complete implementation of "RTPPayload Format for JPEG 2000 Video Streams". That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header.There is an additional media type and Session Description Protocol(SDP) marker signaling for implementations of this document.

RFC 5373 Requesting Answering Modes for the Session Initiation Protocol (SIP)

Authors: D. Willis, Ed., A. Allen.

Date: November 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5373

This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, "Priv-Answer-Mode", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined.

RFC 5374 Multicast Extensions to the Security Architecture for the Internet Protocol

Authors: B. Weis, G. Gross, D. Ignjatic.

Date: November 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5374

The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets. This document describes how the IPsec security services are applied to IP multicast packets. These extensions are relevant only for an IPsec implementation that supports multicast.

RFC 5375 IPv6 Unicast Address Assignment Considerations

Authors: G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn.

Date: December 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5375

One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration ofIPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network.

RFC 5376 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)

Authors: N. Bitar, R. Zhang, K. Kumaki.

Date: November 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5376

Multiprotocol Label Switching Traffic Engineered (MPLS TE) LabelSwitched Paths (LSPs) may be established wholly within an AutonomousSystem (AS) or may cross AS boundaries.
The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCECommunication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as betweenPCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element (PCE) Communication ProtocolGeneric Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLSTE.

RFC 5377 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents

Authors: J. Halpern, Ed..

Date: November 2008

Formats: txt json html

Obsoleted by: RFC 8721

Status: INFORMATIONAL

DOI: 10.17487/RFC 5377

Contributors grant intellectual property rights to the IETF. TheIETF Trust holds and manages those rights on behalf of the IETF. TheTrustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts andRFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETFContributions.

RFC 5378 Rights Contributors Provide to the IETF Trust

Authors: S. Bradner, Ed., J. Contreras, Ed..

Date: November 2008

Formats: txt html json

Obsoletes: RFC 3978, RFC 4748

Updates: RFC 2026

Also: BCP 0078

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5378

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 obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replacesSection 10 of RFC 2026.

RFC 5379 Guidelines for Using the Privacy Mechanism for SIP

Authors: M. Munakata, S. Schubert, T. Ohba.

Date: February 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5379

This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values).

RFC 5380 Hierarchical Mobile IPv6 (HMIPv6) Mobility Management

Authors: H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier.

Date: October 2008

Formats: txt html json

Obsoletes: RFC 4140

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5380

This document introduces extensions to Mobile IPv6 and IPv6 NeighbourDiscovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed.

RFC 5381 Experience of Implementing NETCONF over SOAP

Authors: T. Iijima, Y. Atarashi, H. Kimura, M. Kitani, H. Okita.

Date: October 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5381

This document describes how the authors developed a SOAP (SimpleObject Access Protocol)-based NETCONF (Network ConfigurationProtocol) client and server. It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS(Network Management System) and network equipment that can deal withNETCONF messages sent over SOAP. This document aims to provideNETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server.

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 5383 Deployment Considerations for Lemonade-Compliant Mobile Email

Authors: R. Gellens.

Date: October 2008

Formats: txt json html

Also: BCP 0143

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5383

This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in theIETF lemonade documents.

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 5385 Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs

Authors: J. Touch.

Date: February 2010

Formats: txt html json

Obsoletes: RFC 3285

Status: INFORMATIONAL

DOI: 10.17487/RFC 5385

This document describes the properties and use of a revised MicrosoftWord template (.dot) for writing Internet Drafts and RFCs. It replaces the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for- line identical with RFC Editor-compliant ASCII output. This version obsoletes RFC 3285.
The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools.

RFC 5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec

Authors: N. Williams, M. Richardson.

Date: November 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5386

This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec EncapsulatingSecurity Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but PeerAuthorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security).

RFC 5387 Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)

Authors: J. Touch, D. Black, Y. Wang.

Date: November 2008

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5387

The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (viaKerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.
This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security"(BTNS). The extensions may be used on their own (this use is calledStand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable.

RFC 5388 Information Model and XML Data Model for Traceroute Measurements

Authors: S. Niccolini, S. Tartarelli, J. Quittek, T. Dietz, M. Swany.

Date: December 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5388

This document describes a standard way to store the configuration and the results of traceroute measurements. This document first describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined, dividing the information elements into two semantically separated groups (configuration elements and results elements). Moreover, an additional element is defined to relate configuration elements and results elements by means of a common unique identifier. On the basis of the information model, a data model based on XML is defined to store the results of traceroute measurements.

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 5390 Requirements for Management of Overload in the Session Initiation Protocol

Authors: J. Rosenberg.

Date: December 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5390

Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution.

RFC 5391 RTP Payload Format for ITU-T Recommendation G.711.1

Authors: A. Sollaud.

Date: November 2008

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5391

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication StandardizationSector (ITU-T) G.711.1 audio codec. Two media type registrations are also included.

RFC 5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering

Authors: M. Chen, R. Zhang, X. Duan.

Date: January 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5392

This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) Traffic Engineering (TE) for multipleAutonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS is proposed or defined in this document.

RFC 5393 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies

Authors: R. Sparks, Ed., S. Lawrence, A. Hawrylyshen, B. Campen.

Date: December 2008

Formats: txt json html

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5393

This document normatively updates RFC 3261, the Session InitiationProtocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.
This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement.Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request.

RFC 5394 Policy-Enabled Path Computation Framework

Authors: I. Bryskin, D. Papadimitriou, L. Berger, J. Ash.

Date: December 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5394

The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy.

RFC 5395 Domain Name System (DNS) IANA Considerations

Authors: D. Eastlake 3rd.

Date: November 2008

Formats: txt html json

Obsoletes: RFC 2929

Obsoleted by: RFC 6195

Updates: RFC 1183, RFC 3597

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5395

Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System(DNS) resource record types, CLASSes, operation codes, error codes,DNS protocol message header bits, and AFSDB resource record subtypes.

RFC 5396 Textual Representation of Autonomous System (AS) Numbers

Authors: G. Huston, G. Michaelson.

Date: December 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5396

A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS number. This textual representation is to be used by all documents, systems, and user interfaces referring to AS numbers.

RFC 5397 WebDAV Current Principal Extension

Authors: W. Sanchez, C. Daboo.

Date: December 2008

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5397

This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user.

RFC 5398 Autonomous System (AS) Number Reservation for Documentation Use

Authors: G. Huston.

Date: December 2008

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5398

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of AutonomousSystem numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation.

RFC 5401 Multicast Negative-Acknowledgment (NACK) Building Blocks

Authors: B. Adamson, C. Bormann, M. Handley, J. Macker.

Date: November 2008

Formats: txt html json

Obsoletes: RFC 3941

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5401

This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941.

RFC 5402 Compressed Data within an Internet Electronic Data Interchange (EDI) Message

Authors: T. Harding, Ed..

Date: February 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5402

This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic DataInterchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823.

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 5404 RTP Payload Format for G.719

Authors: M. Westerlund, I. Johansson.

Date: January 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5404

This document specifies the payload format for packetization of theG.719 full-band codec encoded audio signals into the Real-timeTransport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving.

RFC 5405 Unicast UDP Usage Guidelines for Application Designers

Authors: L. Eggert, G. Fairhurst.

Date: November 2008

Formats: txt html json

Obsoleted by: RFC 8085

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5405

The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms.Because congestion control is critical to the stable operation of theInternet, applications and upper-layer protocols that choose to useUDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use ofUDP for the designers of unicast applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal.

RFC 5406 Guidelines for Specifying the Use of IPsec Version 2

Authors: S. Bellovin.

Date: February 2009

Formats: txt json html

Also: BCP 0146

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5406

The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified.

RFC 5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)

Authors: M. Hasebe, J. Koshiko, Y. Suzuki, T. Yoshikawa, P. Kyzivat.

Date: December 2008

Formats: txt json html

Also: BCP 0147

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5407

This document gives example call flows of race conditions in theSession Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows includeSIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given.

RFC 5408 Identity-Based Encryption Architecture and Supporting Data Structures

Authors: G. Appenzeller, L. Martin, M. Schertler.

Date: January 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5408

This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology.

RFC 5409 Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)

Authors: L. Martin, M. Schertler.

Date: January 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5409

This document describes the conventions for using the Boneh-Franklin(BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined.

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 5411 A Hitchhiker's Guide to the Session Initiation Protocol (SIP)

Authors: J. Rosenberg.

Date: February 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5411

The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories.

RFC 5412 Lightweight Access Point Protocol

Authors: P. Calhoun, R. Suri, N. Cam-Winget, M. Williams, S. Hares, B. O'Hara, S. Kelly.

Date: February 2010

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 5412

In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller.
The IETF's CAPWAP (Control and Provisioning of Wireless AccessPoints) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and WirelessTermination Points (the latter are also commonly referred to asLightweight Access Points). This specification defines theLightweight Access Point Protocol (LWAPP), which addresses theCAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol.

RFC 5413 SLAPP: Secure Light Access Point Protocol

Authors: P. Narasimhan, D. Harkins, S. Ponnuswamy.

Date: February 2010

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 5413

The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and AccessControllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another.
In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document.
Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP).

RFC 5414 Wireless LAN Control Protocol (WiCoP)

Authors: S. Iino, S. Govindan, M. Sugiura, H. Cheng.

Date: February 2010

Formats: txt html json

Obsoleted by: RFC 5415

Status: HISTORIC

DOI: 10.17487/RFC 5414

The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points(WTPs) and covering substantial areas are increasingly common.
The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of WirelessAccess Points (CAPWAP).

RFC 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 5416 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11

Authors: P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed..

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5416

Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralizedAccess Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller.
This specification defines the Control And Provisioning of WirelessAccess Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol.

RFC 5417 Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option

Authors: P. Calhoun.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5417

The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover theAccess Controllers to which it is to connect. This document describes the DHCP options to be used by the CAPWAP Protocol.

RFC 5418 Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments

Authors: S. Kelly, T. Clancy.

Date: March 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5418

Early Wireless Local Area Network (WLAN) deployments feature a "fat"Access Point (AP), which serves as a stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control andProvisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments.

RFC 5419 Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)

Authors: B. Patil, G. Dommety.

Date: January 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5419

Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the Binding Update(BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in MobileIPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments.

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 5421 Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)

Authors: N. Cam-Winget, H. Zhou.

Date: March 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5421

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. Within this tunnel, a basic password exchange, based on the Generic TokenCard method (EAP-GTC), may be executed to authenticate the peer.

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 5423 Internet Message Store Events

Authors: R. Gellens, C. Newman.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5423

One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system.
This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP.

RFC 5424 The Syslog Protocol

Authors: R. Gerhards.

Date: March 2009

Formats: txt html json

Obsoletes: RFC 3164

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5424

This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.
This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport.
This document obsoletes RFC 3164.

RFC 5425 Transport Layer Security (TLS) Transport Mapping for Syslog

Authors: F. Miao, Ed., Y. Ma, Ed., J. Salowey, Ed..

Date: March 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5425

This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages.This document describes the security threats to syslog and how TLS can be used to counter such threats.

RFC 5426 Transmission of Syslog Messages over UDP

Authors: A. Okmianski.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5426

This document describes the transport for syslog messages over UDP/IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping.

RFC 5427 Textual Conventions for Syslog Management

Authors: G. Keeni.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5427

This MIB module defines textual conventions to represent Facility andSeverity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations.

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 5429 Sieve Email Filtering: Reject and Extended Reject Extensions

Authors: A. Stone, Ed..

Date: March 2009

Formats: txt html json

Obsoletes: RFC 3028

Updates: RFC 5228

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5429

This memo updates the definition of the Sieve mail filtering language"reject" extension, originally defined in RFC 3028.
A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces,Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs.
This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the"ereject" action to require messages to be refused during the SMTP transaction, if possible.
The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol-level message rejection.

RFC 5430 Suite B Profile for Transport Layer Security (TLS)

Authors: M. Salter, E. Rescorla, R. Housley.

Date: March 2009

Formats: txt html json

Obsoleted by: RFC 6460

Status: HISTORIC

DOI: 10.17487/RFC 5430

The United States government has published guidelines for "NSA SuiteB Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile ofTransport Layer Security (TLS) version 1.2 that is fully conformant with Suite B. This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible.

RFC 5431 Diameter ITU-T Rw Policy Enforcement Interface Application

Authors: D. Sun.

Date: March 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5431

This document describes the need for a new pair of IANA DiameterCommand Codes to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/ response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union -Telecommunication Standardization Sector (ITU-T).

RFC 5432 Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)

Authors: J. Polk, S. Dhesikan, G. Camarillo.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5432

The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish. Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use. However, on theInternet, there is more than one QoS service available.Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism.

RFC 5433 Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method

Authors: T. Clancy, H. Tschofenig.

Date: February 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5433

This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation.

RFC 5434 Considerations for Having a Successful Birds-of-a-Feather (BOF) Session

Authors: T. Narten.

Date: February 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5434

This document discusses tactics and strategy for hosting a successfulIETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful.

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 5436 Sieve Notification Mechanism: mailto

Authors: B. Leiba, M. Haardt.

Date: January 2009

Formats: txt json html

Updates: RFC 3834

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5436

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail.

RFC 5437 Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)

Authors: P. Saint-Andre, A. Melnikov.

Date: January 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5437

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the ExtensibleMessaging and Presence Protocol (XMPP), also known as Jabber.

RFC 5438 Instant Message Disposition Notification (IMDN)

Authors: E. Burger, H. Khartabil.

Date: February 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5438

Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications(IMDN), including delivery, processing, and display notifications, for page-mode instant messages.
The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.
This document also describes how SIP entities behave using this extension.

RFC 5439 An Analysis of Scaling Issues in MPLS-TE Core Networks

Authors: S. Yasukawa, A. Farrel, O. Komolafe.

Date: February 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5439

Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning.
This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks.
This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipointMPLS-TE LSPs are for future study.

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 5441 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths

Authors: JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux.

Date: April 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5441

The ability to compute shortest constrained Traffic Engineering LabelSwitched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers.

RFC 5442 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail

Authors: E. Burger, G. Parsons.

Date: March 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5442

This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email toSupport Diverse Service Environments) working group in the IETF.This document also describes how the LEMONADE architecture meetsOMA's requirements for their Mobile Email (MEM) service.

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 5445 Basic Forward Error Correction (FEC) Schemes

Authors: M. Watson.

Date: March 2009

Formats: txt json html

Obsoletes: RFC 3452, RFC 3695

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5445

This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT)FEC building block for the Compact No-Code FEC Scheme, the SmallBlock, Large Block, and Expandable FEC Scheme, the Small BlockSystematic FEC Scheme, and the Compact FEC Scheme. This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452.

RFC 5446 Service Selection for Mobile IPv4

Authors: J. Korhonen, U. Nilsson.

Date: February 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5446

In some Mobile IPv4 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish among the multiple services possibly provisioned to the mobile node. The capability to specify different services in addition to the mobile node's identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a ServiceSelection extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for their mobility service subscriptions during the registration procedure.

RFC 5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction

Authors: J. Korhonen, Ed., J. Bournelle, H. Tschofenig, C. Perkins, K. Chowdhury.

Date: February 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5447

A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters be statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication,Authorization, and Accounting (AAA) infrastructures. This document describes MIPv6 bootstrapping using the Diameter Network AccessServer to home AAA server interface.

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 5449 OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks

Authors: E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen.

Date: February 2009

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5449

This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type".

RFC 5450 Transmission Time Offsets in RTP Streams

Authors: D. Singer, H. Desineni.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5450

This document describes a method to inform Real-time TransportProtocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times.

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 5452 Measures for Making DNS More Resilient against Forged Answers

Authors: A. Hubert, R. van Mook.

Date: January 2009

Formats: txt html json

Updates: RFC 2181

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5452

The current Internet climate poses serious threats to the Domain NameSystem. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make'spoofing' a recursing nameserver many orders of magnitude harder.
Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.
By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181.

RFC 5453 Reserved IPv6 Interface Identifiers

Authors: S. Krishnan.

Date: February 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5453

Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. AnIPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one.

RFC 5454 Dual-Stack Mobile IPv4

Authors: G. Tsirtsis, V. Park, H. Soliman.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5454

This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual-stack node to use IPv4 andIPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures.

RFC 5455 Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol

Authors: S. Sivabalan, Ed., J. Parker, S. Boutros, K. Kumaki.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5455

This document specifies a CLASSTYPE object to support Diffserv-AwareTraffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE).

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 5457 IANA Considerations for IAX: Inter-Asterisk eXchange Version 2

Authors: E. Guy, Ed..

Date: February 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5457

This document establishes the IANA registries for 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 the Asterisk 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.

RFC 5458 Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol

Authors: H. Cruickshank, P. Pillai, M. Noisternig, S. Iyengar.

Date: March 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5458

The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission.
The analysis also describes applicability to the Generic StreamEncapsulation (GSE) defined by the Digital Video Broadcasting (DVB)Project.

RFC 5459 G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support

Authors: A. Sollaud.

Date: January 2009

Formats: txt json html

Updates: RFC 4749

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5459

This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union(ITU-T) Recommendation G.729.1 audio codec. It adds DiscontinuousTransmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format.

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 5461 TCP's Reaction to Soft Errors

Authors: F. Gont.

Date: February 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5461

This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments.

RFC 5462 Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field

Authors: L. Andersson, R. Asati.

Date: February 2009

Formats: txt html json

Updates: RFC 3032, RFC 3270, RFC 3272, RFC 3443, RFC 3469, RFC 3564, RFC 3985, RFC 4182, RFC 4364, RFC 4379, RFC 4448, RFC 4761, RFC 5129

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5462

The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".
Although the intended use of the EXP field was as a "Class ofService" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.
To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field.

RFC 5463 Sieve Email Filtering: Ihave Extension

Authors: N. Freed.

Date: March 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5463

This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script.

RFC 5464 The IMAP METADATA Extension

Authors: C. Daboo.

Date: February 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5464

The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server.

RFC 5465 The IMAP NOTIFY Extension

Authors: A. Gulbrandsen, C. King, A. Melnikov.

Date: February 2009

Formats: txt json html

Updates: RFC 5267

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5465

This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes.

RFC 5466 IMAP4 Extension for Named Searches (Filters)

Authors: A. Melnikov, C. King.

Date: February 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5466

The document defines a way to persistently store named IMAP (RFC3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter.

RFC 5467 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)

Authors: L. Berger, A. Takacs, D. Caviglia, D. Fedyk, J. Meuric.

Date: March 2009

Formats: txt html json

Obsoleted by: RFC 6387

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5467

This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental.

RFC 5468 Performance Analysis of Inter-Domain Path Computation Methodologies

Authors: S. Dasgupta, J. de Oliveira, JP. Vasseur.

Date: April 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5468

This document presents a performance comparison between the per- domain path computation method and the Path Computation Element (PCE)Architecture-based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified, and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken.

RFC 5469 DES and IDEA Cipher Suites for Transport Layer Security (TLS)

Authors: P. Eronen, Ed..

Date: February 2009

Formats: txt json html

Obsoleted by: RFC 8996

Status: HISTORIC

DOI: 10.17487/RFC 5469

Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES(when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC5246). This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended.

RFC 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 5471 Guidelines for IP Flow Information Export (IPFIX) Testing

Authors: C. Schmoll, P. Aitken, B. Claise.

Date: March 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5471

This document presents a list of tests for implementers of IP FlowInformation eXport (IPFIX) compliant Exporting Processes andCollecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process andCollecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore, they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes.

RFC 5472 IP Flow Information Export (IPFIX) Applicability

Authors: T. Zseby, E. Boschi, N. Brownlee, B. Claise.

Date: March 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5472

In this document, we describe the applicability of the IP FlowInformation eXport (IPFIX) protocol for a variety of applications.We show how applications can use IPFIX, describe the relevantInformation Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks.

RFC 5473 Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports

Authors: E. Boschi, L. Mark, B. Claise.

Date: March 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5473

This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well.
This method works by separating information common to several FlowRecords from information specific to an individual Flow Record.Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier.

RFC 5474 A Framework for Packet Selection and Reporting

Authors: N. Duffield, Ed., D. Chiou, B. Claise, A. Greenberg, M. Grossglauser, J. Rexford.

Date: March 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5474

This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized Selectors, to form a stream of reports on the selected packets, and to export the reports to a Collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting, and exporting are described, along with configuration requirements of thePSAMP functions.

RFC 5475 Sampling and Filtering Techniques for IP Packet Selection

Authors: T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. Raspall.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5475

This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector.

RFC 5476 Packet Sampling (PSAMP) Protocol Specifications

Authors: B. Claise, Ed., A. Johnson, J. Quittek.

Date: March 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5476

This document specifies the export of packet information from aPacket SAMPling (PSAMP) Exporting Process to a PSAMP CollectingProcess. For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well, and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how theIPFIX protocol is used for PSAMP export of packet information.

RFC 5477 Information Model for Packet Sampling Exports

Authors: T. Dietz, B. Claise, P. Aitken, F. Dressler, G. Carle.

Date: March 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5477

This memo defines an information model for the Packet SAMPling(PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process.As the PSAMP protocol is based on the IP Flow Information eXport(IPFIX) protocol, this information model is an extension to the IPFIX information model.

RFC 5478 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces

Authors: J. Polk.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5478

This document creates additional Session Initiation Protocol (SIP)Resource-Priority namespaces to meet the requirements of the USDefense Information Systems Agency, and places these namespaces in the IANA registry.

RFC 5479 Requirements and Analysis of Media Security Management Protocols

Authors: D. Wing, Ed., S. Fries, H. Tschofenig, F. Audet.

Date: April 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5479

This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document.

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 5481 Packet Delay Variation Applicability Statement

Authors: A. Morton, B. Claise.

Date: March 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5481

Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions.
Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks.

RFC 5482 TCP User Timeout Option

Authors: L. Eggert, F. Gont.

Date: March 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5482

The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity.

RFC 5483 ENUM Implementation Issues and Experiences

Authors: L. Conroy, K. Fujiwara.

Date: March 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5483

This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic DelegationDiscovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents.

RFC 5484 Associating Time-Codes with RTP Streams

Authors: D. Singer.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5484

This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers(SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself.

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 5486 Session Peering for Multimedia Interconnect (SPEERMINT) Terminology

Authors: D. Malas, Ed., D. Meyer, Ed..

Date: March 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5486

This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT).

RFC 5487 Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode

Authors: M. Badra.

Date: March 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5487

RFC 4279 and RFC 4785 describe pre-shared key cipher suites forTransport Layer Security (TLS). However, all those cipher suites useSHA-1 in their Message Authentication Code (MAC) algorithm. This document describes a set of pre-shared key cipher suites for TLS that uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set that uses the Advanced Encryption Standard (AES) inGalois Counter Mode (GCM).

RFC 5488 Network Mobility (NEMO) Management Information Base

Authors: S. Gundavelli, G. Keeni, K. Koide, K. Nagami.

Date: April 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5488

This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community. In particular, theNEMO MIB will be used to monitor and control a Mobile IPv6 node withNEMO functionality.

RFC 5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)

Authors: M. Badra, I. Hajjeh.

Date: March 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5489

This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE). These cipher suites provide Perfect Forward Secrecy(PFS).

RFC 5490 The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata

Authors: A. Melnikov.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5490

This memo defines an extension to the Sieve mail filtering language(RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action.

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 5493 Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network

Authors: D. Caviglia, D. Bramanti, D. Li, D. McDysan.

Date: April 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5493

From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched.
This memo sets out the requirements for such procedures within aGeneralized Multiprotocol Label Switching (GMPLS) network.

RFC 5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP)

Authors: J. Arkko, C. Pignataro.

Date: April 2009

Formats: txt json html

Updates: RFC 0826, RFC 0951, RFC 1044, RFC 1329, RFC 2131, RFC 2132, RFC 2176, RFC 2225, RFC 2834, RFC 2835, RFC 3315, RFC 4338, RFC 4361, RFC 4701

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5494

This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces.

RFC 5495 Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures

Authors: D. Li, J. Gao, A. Satyanarayana, S. Bardalai.

Date: March 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5495

The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in aMultiprotocol Label Switching (MPLS) traffic-engineered (TE) network.The Hello message has been extended for use in Generalized MPLS(GMPLS) networks for state recovery of control channel or nodal faults.
The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a LabelSwitched Path (LSP).
Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchangingRSVP messages with its upstream and downstream neighbors.
This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.
This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents.

RFC 5496 The Reverse Path Forwarding (RPF) Vector TLV

Authors: IJ. Wijnands, A. Boers, E. Rosen.

Date: March 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5496

This document describes a use of the Protocol Independent Multicast(PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree.

RFC 5497 Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)

Authors: T. Clausen, C. Dearlove.

Date: March 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5497

This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address BlockTLVs for representing validity and interval times for MANET routing protocols.

RFC 5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols

Authors: I. Chakeres.

Date: March 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5498

This document enumerates several common IANA allocations for use byMobile Ad hoc NETwork (MANET) protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address.

RFC 5501 Requirements for Multicast Support in Virtual Private LAN Services

Authors: Y. Kamite, Ed., Y. Wada, Y. Serbest, T. Morin, L. Fang.

Date: March 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5501

This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines.

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 5503 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture

Authors: F. Andreasen, B. McKibben, B. Marshall.

Date: March 2009

Formats: txt html json

Obsoletes: RFC 3603

Status: INFORMATIONAL

DOI: 10.17487/RFC 5503

In order to deploy a residential telephone service at a very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol, RFC 3261, for supporting the exchange of customer information and billing information between trusted entities in the PacketCable DistributedCall Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.

RFC 5504 Downgrading Mechanism for Email Address Internationalization

Authors: K. Fujiwara, Ed., Y. Yoneya, Ed..

Date: March 2009

Formats: txt json html

Obsoleted by: RFC 6530

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5504

Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email AddressInternationalization (UTF8SMTP) extension allows UTF-8 characters inSMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages.

RFC 5505 Principles of Internet Host Configuration

Authors: B. Aboba, D. Thaler, L. Andersson, S. Cheshire.

Date: May 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5505

This document describes principles of Internet host configuration.It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols.

RFC 5506 Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences

Authors: I. Johansson, M. Westerlund.

Date: April 2009

Formats: txt html json

Updates: RFC 3550, RFC 3711, RFC 4585

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5506

This memo discusses benefits and issues that arise when allowingReal-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time TransportProtocol / Audio-Visual Profile with Feedback) profile (RFC 4585).This document updates RFC 3550, RFC 3711, and RFC 4585.

RFC 5507 Design Choices When Expanding the DNS

Authors: IAB, P. Faltstrom, Ed., R. Austein, Ed., P. Koch, Ed..

Date: April 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5507

This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNSResource Record Type is the best solution.

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 5509 Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)

Authors: S. Loreto.

Date: April 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5509

This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP.

RFC 5510 Reed-Solomon Forward Error Correction (FEC) Schemes

Authors: J. Lacan, V. Roca, J. Peltotalo, S. Peltotalo.

Date: April 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5510

This document describes a Fully-Specified Forward Error Correction(FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-SpecifiedFEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC EncodingID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8).
Reed-Solomon codes belong to the class of Maximum Distance Separable(MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo.

RFC 5511 Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications

Authors: A. Farrel.

Date: April 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5511

Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.
There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.
Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.
This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols.

RFC 5512 The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute

Authors: P. Mohapatra, E. Rosen.

Date: April 2009

Formats: txt html json

Obsoleted by: RFC 9012

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5512

In certain situations, transporting a packet from one Border GatewayProtocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the"encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.
The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such asLayer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic RoutingEncapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using theEncapsulation Subsequent Address Family Identifier (SAFI) and theIPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used.

RFC 5513 IANA Considerations for Three Letter Acronyms

Authors: A. Farrel.

Date: 1 April 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5513

Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions.While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of theInternet as misunderstandings lead to misconfiguration or other operating errors.
Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry.

RFC 5514 IPv6 over Social Networks

Authors: E. Vyncke.

Date: 1 April 2009

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5514

There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks.This will immediately add millions of IPv6 hosts to the existing IPv6Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed.

RFC 5515 Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions

Authors: V. Mammoliti, C. Pignataro, P. Arberg, J. Gibbons, P. Howard.

Date: May 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5515

This document describes a set of Layer 2 Tunneling Protocol (L2TP)Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality. It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment. The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. TheL2TP AVPs defined in this document are applicable to both L2TPv2 andL2TPv3.

RFC 5516 Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)

Authors: M. Jones, L. Morand.

Date: April 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5516

This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for theThird Generation Partnership Project (3GPP) Evolved Packet System(EPS). These new Diameter applications are defined for MobileManagement Entity (MME)- and Serving GPRS (General Packet RadioService) Support Node (SGSN)-related interfaces in in the architecture for the Evolved 3GPP Packet Switched Domain, which is also known as the Evolved Packet System (EPS).

RFC 5517 Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment

Authors: S. HomChaudhuri, M. Foschiano.

Date: February 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5517

This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints.Such a mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead.
Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the- home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details.

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 5519 Multicast Group Membership Discovery MIB

Authors: J. Chesterfield, B. Haberman, Ed..

Date: April 2009

Formats: txt json html

Obsoletes: RFC 2933, RFC 3019

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5519

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing the InternetGroup Management Protocol (IGMP) and the Multicast Listener Discovery(MLD) protocol.

RFC 5520 Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism

Authors: R. Bradford, Ed., JP. Vasseur, A. Farrel.

Date: April 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5520

Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., whenASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information.This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary LabelSwitching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.
This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCECommunication Protocol (PCEP) and signaled within in a ResourceReservation Protocol TE (RSVP-TE) explicit route object.

RFC 5521 Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions

Authors: E. Oki, T. Takeda, A. Farrel.

Date: April 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5521

The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-ProtocolLabel Switching (MPLS) and Generalized MPLS (GMPLS) networks.
When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups(SRLGs) that are to be explicitly excluded from the computed route.Such constraints are termed "route exclusions".
The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions.

RFC 5522 Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks

Authors: W. Eddy, W. Ivancic, T. Davis.

Date: October 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5522

This document describes the requirements and desired properties ofNetwork Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration.
Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of theInternational Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies.

RFC 5523 OSPFv3-Based Layer 1 VPN Auto-Discovery

Authors: L. Berger.

Date: April 2009

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5523

This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6.

RFC 5524 Extended URLFETCH for Binary and Converted Parts

Authors: D. Cridland.

Date: May 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5524

The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications.

RFC 5525 Reliable Server Pooling MIB Module Definition

Authors: T. Dreibholz, J. Mulik.

Date: April 2009

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5525

Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling. The RSerPool framework consists of two protocols:ASAP (Aggregate Server Access Protocol) and ENRP (EndpointHandlespace Redundancy Protocol). This document defines an SMIv2- compliant (Structure of Management Information Version 2) ManagementInformation Base (MIB) module providing access to managed objects in an RSerPool implementation.

RFC 5526 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM

Authors: J. Livingood, P. Pfautz, R. Stastny.

Date: April 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5526

This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa", as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees).

RFC 5527 Combined User and Infrastructure ENUM in the e164.arpa Tree

Authors: M. Haberler, O. Lendl, R. Stastny.

Date: May 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5527

This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution.

RFC 5528 Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms

Authors: A. Kato, M. Kanda, S. Kanno.

Date: April 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5528

This document describes the algorithms and presents test vectors for the Camellia block cipher algorithm in Counter mode (CTR) and Counter with Cipher Block Chaining MAC mode (CCM). The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community.

RFC 5529 Modes of Operation for Camellia for Use with IPsec

Authors: A. Kato, M. Kanda, S. Kanno.

Date: April 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5529

This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode as additional, optional-to- implement Internet Key Exchange Protocol version 2 (IKEv2) andEncapsulating Security Payload (ESP) mechanisms to provide confidentiality, data origin authentication, and connectionless integrity.

RFC 5530 IMAP Response Codes

Authors: A. Gulbrandsen.

Date: May 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5530

IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.
This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting.

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 5532 Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement

Authors: T. Talpey, C. Juszczak.

Date: May 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5532

This document addresses enabling the use of Remote Direct MemoryAccess (RDMA) by the Network File System (NFS) protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead.This document explores the potential benefits of RDMA to these implementations and evaluates the reasons why RDMA is especially well-suited to NFS and network file protocols in general.

RFC 5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6

Authors: E. Nordmark, M. Bagnulo.

Date: June 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5533

This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working.

RFC 5534 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming

Authors: J. Arkko, I. van Beijnum.

Date: June 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5534

This document specifies how the level 3 multihoming Shim6 protocol(Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found.

RFC 5535 Hash-Based Addresses (HBA)

Authors: M. Bagnulo.

Date: June 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5535

This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs eitherCryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other.

RFC 5536 Netnews Article Format

Authors: K. Murchison, Ed., C. Lindsey, D. Kohn.

Date: November 2009

Formats: txt html json

Obsoletes: RFC 1036, RFC 1849

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5536

This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose InternetMail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents.

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 5538 The 'news' and 'nntp' URI Schemes

Authors: F. Ellermann.

Date: April 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5538

This memo specifies the 'news' and 'nntp' Uniform Resource Identifier(URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on the Standards Track.

RFC 5539 NETCONF over Transport Layer Security (TLS)

Authors: M. Badra.

Date: May 2009

Formats: txt json html

Obsoleted by: RFC 7589

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5539

The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices.This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges.

RFC 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 5541 Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)

Authors: JL. Le Roux, JP. Vasseur, Y. Lee.

Date: June 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5541

The computation of one or a set of Traffic Engineering Label SwitchedPaths (TE LSPs) in MultiProtocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions(e.g., minimum cost path, widest path, etc.).
In the Path Computation Element (PCE) architecture, a PathComputation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, thePCC needs to instruct the PCE to use the correct objective function.Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.
This document defines extensions to the PCE communication Protocol(PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.
This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests.

RFC 5542 Definitions of Textual Conventions for Pseudowire (PW) Management

Authors: T. Nadeau, Ed., D. Zelig, Ed., O. Nicklass, Ed..

Date: May 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5542

This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations.

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 5547 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer

Authors: M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat.

Date: May 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5547

This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session DescriptionProtocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred.The offerer can describe either the files it wants to send or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation.The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document.

RFC 5548 Routing Requirements for Urban Low-Power and Lossy Networks

Authors: M. Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed..

Date: May 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5548

The application-specific routing requirements for Urban Low-Power andLossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws.These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions). The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-powerIEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics.

RFC 5549 Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop

Authors: F. Le Faucheur, E. Rosen.

Date: May 2009

Formats: txt html json

Obsoleted by: RFC 8950

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5549

Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and theSubsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) orVPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop forIPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowingMP-BGP Peers to dynamically discover whether they can exchange IPv4NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.

RFC 5550 The Internet Email to Support Diverse Service Environments (Lemonade) Profile

Authors: D. Cridland, Ed., A. Melnikov, Ed., S. Maes, Ed..

Date: August 2009

Formats: txt html json

Obsoletes: RFC 4550

Updates: RFC 4469, RFC 4467

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5550

This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients(especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP andSubmission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.
The Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords.

RFC 5551 Lemonade Notifications Architecture

Authors: R. Gellens, Ed..

Date: August 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5551

Notification and filtering mechanisms can make email more enjoyable on mobile and other constrained devices (such as those with limited screen sizes, memory, data transfer rates, etc.). Notifications make the client aware of significant events (such as the arrival of new mail) so it can react (such as by fetching interesting mail immediately). Filtering reduces the visible mail to a set of messages that meet some criteria for "interesting". This functionality is included in the goals of the Lemonade (Enhancements to Internet email to Support Diverse Service Environments) WorkingGroup.
This document also discusses the use of server-to-server notifications, and how server to server notifications fit into an architecture that provides server to client notifications.

RFC 5552 SIP Interface to VoiceXML Media Services

Authors: D. Burke, M. Scott.

Date: May 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5552

This document describes a SIP interface to VoiceXML media services.Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism.

RFC 5553 Resource Reservation Protocol (RSVP) Extensions for Path Key Support

Authors: A. Farrel, Ed., R. Bradford, JP. Vasseur.

Date: May 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5553

The paths taken by Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) Traffic Engineering (TE) Label SwitchedPaths (LSPs) may be computed by Path Computation Elements (PCEs).Where the TE LSP crosses multiple domains, such as Autonomous Systems(ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path.
To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called theConfidential Path Segment (CPS), by encoding the contents as a PathKey Subobject (PKS) and embedding this subobject within the result of its path computation.
This document describes how to carry Path Key Subobjects in theResource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs.

RFC 5554 Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings

Authors: N. Williams.

Date: May 2009

Formats: txt html json

Updates: RFC 2743

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5554

This document clarifies and generalizes the Generic Security ServiceApplication Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API.

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 5556 Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement

Authors: J. Touch, R. Perlman.

Date: May 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5556

Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths(in the case of spanning trees). This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with802.1, including hubs, bridges, and their existing plug-and-play capabilities.

RFC 5557 Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization

Authors: Y. Lee, JL. Le Roux, D. King, E. Oki.

Date: July 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5557

The Path Computation Element Communication Protocol (PCEP) allowsPath Computation Clients (PCCs) to request path computations fromPath Computation Elements (PCEs), and lets the PCEs return responses.When computing or reoptimizing the routes of a set of TrafficEngineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions.Such bulk optimization is termed Global Concurrent Optimization(GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.
This document provides application-specific requirements and the PCEP extensions in support of GCO applications.

RFC 5558 Virtual Enterprise Traversal (VET)

Authors: F. Templin, Ed..

Date: February 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5558

Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet.Enterprise network nodes require a means to automatically provisionIP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks.

RFC 5559 Pre-Congestion Notification (PCN) Architecture

Authors: P. Eardley, Ed..

Date: June 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5559

This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain.

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 5561 LDP Capabilities

Authors: B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux.

Date: July 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5561

A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements afterLDP session establishment.

RFC 5562 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets

Authors: A. Kuzmanovic, A. Mondal, S. Floyd, K. Ramakrishnan.

Date: June 2009

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5562

The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of ExplicitCongestion Notification (ECN) in TCP SYN/ACK packets.
This document describes an optional, experimental modification to RFC3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use ofECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet asECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder(the sender of the SYN/ACK packet) must reply to a report of an ECN- marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer).

RFC 5563 WiMAX Forum / 3GPP2 Proxy Mobile IPv4

Authors: K. Leung, G. Dommety, P. Yegani, K. Chowdhury.

Date: February 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5563

Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility- unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2.

RFC 5564 Linguistic Guidelines for the Use of the Arabic Language in Internet Domains

Authors: A. El-Sherbiny, M. Farah, I. Oueichek, A. Al-Zoman.

Date: February 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5564

This document constitutes technical specifications for the use ofArabic in Internet domain names and provides linguistic guidelines for Arabic domain names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names.

RFC 5565 Softwire Mesh Framework

Authors: J. Wu, Y. Cui, C. Metz, E. Rosen.

Date: June 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5565

The Internet needs to be able to handle both IPv4 and IPv6 packets.However, it is expected that some constituent networks of theInternet will be "single-protocol" networks. One kind of single- protocol network can parse only IPv4 packets and can process onlyIPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology.

RFC 5566 BGP IPsec Tunnel Encapsulation Attribute

Authors: L. Berger, R. White, E. Rosen.

Date: June 2009

Formats: txt json html

Obsoleted by: RFC 9012

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5566

The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for GenericRouting Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), andIP in IP tunnel types are defined. This document defines support forIPsec tunnel types.

RFC 5567 An Architectural Framework for Media Server Control

Authors: T. Melanchuk, Ed..

Date: June 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5567

This document describes an architectural framework for Media Server control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them.

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 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

Authors: R. Despres.

Date: January 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5569

IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deployIPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure.Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it.

RFC 5570 Common Architecture Label IPv6 Security Option (CALIPSO)

Authors: M. StJohns, R. Atkinson, G. Thomas.

Date: July 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5570

This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy.

RFC 5571 Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)

Authors: B. Storer, C. Pignataro, Ed., M. Dos Santos, B. Stevant, Ed., L. Toutain, J. Tremblay.

Date: June 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5571

This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2).The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations.

RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)

Authors: M. Blanchet, F. Parent.

Date: February 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5572

A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 orIPv4, inside various outer protocols packets, such as IPv4, IPv6, orUDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model.

RFC 5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)

Authors: M. Thomson.

Date: June 2009

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5573

The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels.

RFC 5574 RTP Payload Format for the Speex Codec

Authors: G. Herlein, J. Valin, A. Heggestad, A. Moizard.

Date: June 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5574

Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with theSession Description Protocol (SDP).

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 5576 Source-Specific Media Attributes in the Session Description Protocol (SDP)

Authors: J. Lennox, J. Ott, T. Schierl.

Date: June 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5576

The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, inSDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources.

RFC 5577 RTP Payload Format for ITU-T Recommendation G.722.1

Authors: P. Luthi, R. Even.

Date: July 2009

Formats: txt json html

Obsoletes: RFC 3047

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5577

International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of theSession Description Protocol (SDP) parameters needed to supportG.722.1 audio codec.

RFC 5578 PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics

Authors: B. Berry, Ed., S. Ratliff, E. Paradise, T. Kaiser, M. Adams.

Date: February 2010

Formats: txt html json

Obsoletes: RFC 4938

Status: INFORMATIONAL

DOI: 10.17487/RFC 5578

This document extends the Point-to-Point Protocol over Ethernet(PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links.

RFC 5579 Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces

Authors: F. Templin, Ed..

Date: February 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5579

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automaticIPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces.

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 5581 The Camellia Cipher in OpenPGP

Authors: D. Shaw.

Date: June 2009

Formats: txt html json

Updates: RFC 4880

Status: INFORMATIONAL

DOI: 10.17487/RFC 5581

This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol.

RFC 5582 Location-to-URL Mapping Architecture and Framework

Authors: H. Schulzrinne.

Date: September 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5582

RFC 5583 Signaling Media Decoding Dependency in the Session Description Protocol (SDP)

Authors: T. Schierl, S. Wenger.

Date: July 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5583

This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.
A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s).

RFC 5584 RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family

Authors: M. Hatanaka, J. Matsumoto.

Date: July 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5584

This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the AdaptiveTRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming.

RFC 5585 DomainKeys Identified Mail (DKIM) Service Overview

Authors: T. Hansen, D. Crocker, P. Hallam-Baker.

Date: July 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5585

This document provides an overview of the DomainKeys Identified Mail(DKIM) service and describes how it can fit into a messaging service.It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public- key cryptography, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages.DKIM's authentication of email identity can assist in the global control of "spam" and "phishing".

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 5587 Extended Generic Security Service Mechanism Inquiry APIs

Authors: N. Williams.

Date: July 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5587

This document introduces new application programming interfaces(APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications.
These interfaces include mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that possess given attributes, and a function for displaying mechanism attributes.

RFC 5588 Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials

Authors: N. Williams.

Date: July 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5588

This document defines a new function for the Generic Security ServiceApplication Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials.

RFC 5589 Session Initiation Protocol (SIP) Call Control - Transfer

Authors: R. Sparks, A. Johnston, Ed., D. Petrie.

Date: June 2009

Formats: txt html json

Also: BCP 0149

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5589

This document describes providing Call Transfer capabilities in theSession Initiation Protocol (SIP). SIP extensions such as REFER andReplaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework.

RFC 5590 Transport Subsystem for the Simple Network Management Protocol (SNMP)

Authors: D. Harrington, J. Schoenwaelder.

Date: June 2009

Formats: txt html json

Updates: RFC 3411, RFC 3412, RFC 3414, RFC 3417

Also: STD 0078

Status: INTERNET STANDARD

DOI: 10.17487/RFC 5590

This document defines a Transport Subsystem, extending the SimpleNetwork Management Protocol (SNMP) architecture defined in RFC 3411.This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security
(TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP.

RFC 5591 Transport Security Model for the Simple Network Management Protocol (SNMP)

Authors: D. Harrington, W. Hardaker.

Date: June 2009

Formats: txt html json

Also: STD 0078

Status: INTERNET STANDARD

DOI: 10.17487/RFC 5591

This memo describes a Transport Security Model for the Simple NetworkManagement Protocol (SNMP).
This memo also defines a portion of the Management Information Base(MIB) for monitoring and managing the Transport Security Model forSNMP.

RFC 5592 Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)

Authors: D. Harrington, J. Salowey, W. Hardaker.

Date: June 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5592

This memo describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), using the Secure Shell (SSH) protocol.
This memo also 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 monitoring and managing the Secure Shell Transport Model for SNMP.

RFC 5593 Internet Message Access Protocol (IMAP) - URL Access Identifier Extension

Authors: N. Cook.

Date: June 2009

Formats: txt json html

Updates: RFC 5092

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5593

The existing IMAP URL specification (RFC 5092) lists several <access&rt; identifiers and <access&rt; identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access&rt; identifiers as well as an IANA mechanism to register new <access&rt; identifiers for future applications.
This document updates RFC 5092.

RFC 5594 Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008

Authors: J. Peterson, A. Cooper.

Date: July 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5594

This document reports the outcome of a workshop organized by theReal-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in theIETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community.

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 5596 Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal

Authors: G. Fairhurst.

Date: September 2009

Formats: txt json html

Updates: RFC 4340

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5596

This document specifies an update to the Datagram Congestion ControlProtocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., aNetwork Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state.

RFC 5597 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol

Authors: R. Denis-Courmont.

Date: September 2009

Formats: txt json html

Also: BCP 0150

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5597

This document defines a set of requirements for NATs handling theDatagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements forNATs, which have already been published by the IETF. Ensuring thatNATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly.

RFC 5598 Internet Mail Architecture

Authors: D. Crocker.

Date: July 2009

Formats: txt html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5598

Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service.

RFC 5601 Pseudowire (PW) Management Information Base (MIB)

Authors: T. Nadeau, Ed., D. Zelig, Ed..

Date: July 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5601

This memo defines a Standards Track portion of the ManagementInformation Base for use with network management protocols in theInternet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a generalPacket Switched Network.

RFC 5602 Pseudowire (PW) over MPLS PSN Management Information Base (MIB)

Authors: D. Zelig, Ed., T. Nadeau, Ed..

Date: July 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5602

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a MIB module for PW operation overMultiprotocol Label Switching (MPLS) Label Switching Routers (LSRs).

RFC 5603 Ethernet Pseudowire (PW) Management Information Base (MIB)

Authors: D. Zelig, Ed., T. Nadeau, Ed..

Date: July 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5603

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services.

RFC 5604 Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs)

Authors: O. Nicklass.

Date: July 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5604

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 pseudowire encapsulation for structured or unstructured Time-DivisionMultiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet SwitchedNetwork (PSN).

RFC 5605 Managed Objects for ATM over Packet Switched Networks (PSNs)

Authors: O. Nicklass, T. Nadeau.

Date: July 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5605

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling ATMPseudowire (PW) carrying ATM cells over Packet Switched Networks(PSNs).

RFC 5606 Implications of 'retransmission-allowed' for SIP Location Conveyance

Authors: J. Peterson, T. Hardie, J. Morris.

Date: August 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5606

This document explores an ambiguity in the interpretation of the<retransmission-allowed&rt; element of the Presence Information DataFormat for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.
Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader.

RFC 5607 Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management

Authors: D. Nelson, G. Weber.

Date: July 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5607

This document specifies Remote Authentication Dial-In User Service(RADIUS) attributes for authorizing management access to a NetworkAccess Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol.

RFC 5608 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models

Authors: K. Narayan, D. Nelson.

Date: August 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5608

This memo describes the use of a Remote Authentication Dial-In UserService (RADIUS) authentication and authorization service with SimpleNetwork Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model.

RFC 5609 State Machines for the Protocol for Carrying Authentication for Network Access (PANA)

Authors: V. Fajardo, Ed., Y. Ohba, R. Marin-Lopez.

Date: August 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5609

This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA). The state machines consist of the PANA Client (PaC) state machine and the PANAAuthentication Agent (PAA) state machine. The two state machines show how PANA can interface with the Extensible AuthenticationProtocol (EAP) state machines. The state machines and associated models are informative only. Implementations may achieve the same results using different methods.

RFC 5610 Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements

Authors: E. Boschi, B. Trammell, L. Mark, T. Zseby.

Date: July 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5610

This document describes an extension to the IP Flow InformationExport (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools.

RFC 5611 Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires

Authors: A. Vainshtein, S. Galtzur.

Date: August 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5611

This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure- aware (Circuit Emulation Service over Packet Switched Network(CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires.Support of structure-aware (Time-Division Multiplexing over IP(TDMoIP) style) pseudowires over L2TPv3 is left for further study.

RFC 5612 Enterprise Number for Documentation Use

Authors: P. Eronen, D. Harrington.

Date: August 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5612

This document describes an Enterprise Number (also known as SMINetwork Management Private Enterprise Code) for use in documentation.

RFC 5613 OSPF Link-Local Signaling

Authors: A. Zinin, A. Roy, L. Nguyen, B. Friedman, D. Yeung.

Date: August 2009

Formats: txt json html

Obsoletes: RFC 4813

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5613

OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well- defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track.

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 5615 H.248/MEGACO Registration Procedures

Authors: C. Groves, Y. Lin.

Date: August 2009

Formats: txt html json

Also: BCP 0151

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5615

This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process.

RFC 5616 Streaming Internet Messaging Attachments

Authors: N. Cook.

Date: August 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5616

This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from anIMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.
The document describes a profile for making use of the URLAUTH- authorized IMAP URLs (RFC 5092), the Network Announcement SIP MediaService (RFC 4240), and the Media Server Control Markup Language (RFC5022).

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 5618 Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)

Authors: A. Morton, K. Hedayat.

Date: August 2009

Formats: txt html json

Updates: RFC 5357

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5618

This memo describes a simple extension to TWAMP (the Two-Way ActiveMeasurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry.

RFC 5619 Softwire Security Analysis and Requirements

Authors: S. Yamamoto, C. Williams, H. Yokota, F. Parent.

Date: August 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5619

This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets.

RFC 5620 RFC Editor Model (Version 1)

Authors: O. Kolkman, Ed., IAB.

Date: August 2009

Formats: txt html json

Obsoleted by: RFC 6548, RFC 6635

Status: INFORMATIONAL

DOI: 10.17487/RFC 5620

The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent SubmissionEditor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional)Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency.

RFC 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 5623 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering

Authors: E. Oki, T. Takeda, JL. Le Roux, A. Farrel.

Date: September 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5623

A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. ThePath Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering.
This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual NetworkTopology Manager (VNTM).

RFC 5624 Quality of Service Parameters for Usage with Diameter

Authors: J. Korhonen, Ed., H. Tschofenig, E. Davies.

Date: August 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5624

This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.
The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per- hop behavior class object.

RFC 5625 DNS Proxy Implementation Guidelines

Authors: R. Bellis.

Date: August 2009

Formats: txt html json

Also: BCP 0152

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5625

This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices.

RFC 5626 Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)

Authors: C. Jennings, Ed., R. Mahy, Ed., F. Audet, Ed..

Date: October 2009

Formats: txt json html

Updates: RFC 3261, RFC 3327

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5626

The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams toUser Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by theUser Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar.

RFC 5627 Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)

Authors: J. Rosenberg.

Date: October 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5627

Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called aGlobally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog.

RFC 5628 Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)

Authors: P. Kyzivat.

Date: October 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5628

RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.
However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI(GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar.

RFC 5629 A Framework for Application Interaction in the Session Initiation Protocol (SIP)

Authors: J. Rosenberg.

Date: October 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5629

This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent (UA) to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi-Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework.

RFC 5630 The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)

Authors: F. Audet.

Date: October 2009

Formats: txt html json

Updates: RFC 3261, RFC 3608

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5630

This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP).It also makes normative changes to SIP.

RFC 5631 Session Initiation Protocol (SIP) Session Mobility

Authors: R. Shacham, H. Schulzrinne, S. Thakolsri, W. Kellerer.

Date: October 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5631

Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP).Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is an informational document.

RFC 5632 Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial

Authors: C. Griffiths, J. Livingood, L. Popkin, R. Woundy, Y. Yang.

Date: September 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5632

This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a ProactiveNetwork Provider Participation for P2P (P4P) technical trial in July2008. This trial used P4P iTracker technology, which is being considered by the IETF as part of the Application Layer TransportOptimization (ALTO) working group.

RFC 5633 Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers

Authors: S. Dawkins, Ed..

Date: August 2009

Formats: txt json html

Obsoleted by: RFC 7437

Updates: RFC 3777

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5633

This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President.

RFC 5634 Quick-Start for the Datagram Congestion Control Protocol (DCCP)

Authors: G. Fairhurst, A. Sathiaseelan.

Date: August 2009

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5634

This document specifies the use of the Quick-Start mechanism by theDatagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID3, and CCID 4. Quick-Start enables a DCCP sender to cooperate withQuick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the globalInternet.

RFC 5635 Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)

Authors: W. Kumari, D. McPherson.

Date: August 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5635

Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks.This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well.

RFC 5636 Traceable Anonymous Certificate

Authors: S. Park, H. Park, Y. Won, J. Lee, S. Kent.

Date: August 2009

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5636

This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called TraceableAnonymous Certificates (TACs).

RFC 5637 Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6

Authors: G. Giaretta, I. Guardini, E. Demaria, J. Bournelle, R. Lopez.

Date: September 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5637

In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, andAccounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface.

RFC 5638 Simple SIP Usage Scenario for Applications in the Endpoints

Authors: H. Sinnreich, Ed., A. Johnston, E. Shim, K. Singh.

Date: September 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5638

For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with richInternet applications (RIAs). Significant telephony features may also be implemented in the endpoints.
This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about11.
References for NAT traversal and for security are also provided.

RFC 5639 Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation

Authors: M. Lochter, J. Merkle.

Date: March 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5639

This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), TransportLayer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS).

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 5641 Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values

Authors: N. McGill, C. Pignataro.

Date: August 2009

Formats: txt json html

Updates: RFC 3931, RFC 4349, RFC 4454, RFC 4591, RFC 4719

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5641

This document defines additional Layer 2 Tunneling Protocol Version 3(L2TPv3) bit values to be used within the "Circuit Status" AttributeValue Pair (AVP) to communicate finer-grained error states forAttachment Circuits (ACs) and pseudowires (PWs). It also generalizes the Active bit and deprecates the use of the New bit in the CircuitStatus AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC4719.

RFC 5642 Dynamic Hostname Exchange Mechanism for OSPF

Authors: S. Venkata, S. Harwani, C. Pignataro, D. McPherson.

Date: August 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5642

This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS. This mechanism is applicable to both OSPFv2 and OSPFv3.

RFC 5643 Management Information Base for OSPFv3

Authors: D. Joyal, Ed., V. Manral, Ed..

Date: August 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5643

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets.In particular, it defines objects for managing the Open Shortest PathFirst (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3).

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 5645 Update to the Language Subtag Registry

Authors: D. Ewell, Ed..

Date: September 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5645

This memo defines the procedure used to update the IANA LanguageSubtag Registry, in conjunction with the publication of RFC 5646, for use in forming tags for identifying languages.

RFC 5646 Tags for Identifying Languages

Authors: A. Phillips, Ed., M. Davis, Ed..

Date: September 2009

Formats: txt html json

Obsoletes: RFC 4646

Also: BCP 0047

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5646

This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.

RFC 5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol

Authors: K. Igoe, J. Solinas.

Date: August 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5647

Secure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH TransportLayer Protocol.

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 5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm

Authors: R. Housley, M. Dworkin.

Date: September 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5649

This document specifies a padding convention for use with the AES KeyWrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of64 bits, allowing a key of any practical length to be wrapped.

RFC 5650 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)

Authors: M. Morgenstern, S. Baillie, U. Bonollo.

Date: September 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5650

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the"Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing Asymmetric Digital SubscriberLine (ADSL), ADSL2, and ADSL2+ interfaces.

RFC 5651 Layered Coding Transport (LCT) Building Block

Authors: M. Luby, M. Watson, L. Vicisano.

Date: October 2009

Formats: txt json html

Obsoletes: RFC 3451

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5651

The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols usingIP multicast, but it also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This document obsoletes RFC 3451.

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 5653 Generic Security Service API Version 2: Java Bindings Update

Authors: M. Upadhyay, S. Malkani.

Date: August 2009

Formats: txt html json

Obsoletes: RFC 2853

Obsoleted by: RFC 8353

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5653

The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in"Generic Security Service API Version 2 : Java Bindings" (RFC 2853).This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience.
The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2,Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "TheKerberos Version 5 Generic Security Service Application ProgramInterface (GSS-API) Mechanism: Version 2" (RFC 4121).

RFC 5654 Requirements of an MPLS Transport Profile

Authors: B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., N. Sprecher, S. Ueno.

Date: September 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5654

This document specifies the requirements of an MPLS Transport Profile(MPLS-TP). This document is a product of a joint effort of theInternational Telecommunications Union (ITU) and IETF to include anMPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union -Telecommunications Standardization Sector (ITU-T).
This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.
The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements.

RFC 5655 Specification of the IP Flow Information Export (IPFIX) File Format

Authors: B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner.

Date: October 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5655

This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools.

RFC 5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer

Authors: D. Stebila, J. Green.

Date: December 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5656

This document describes algorithms based on Elliptic CurveCryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman(ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol.

RFC 5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard

Authors: L. Dusseault, R. Sparks.

Date: September 2009

Formats: txt html json

Updates: RFC 2026

Also: BCP 0009

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5657

Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report.

RFC 5658 Addressing Record-Route Issues in the Session Initiation Protocol (SIP)

Authors: T. Froment, C. Lebel, B. Bonnaerens.

Date: October 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5658

A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it.This header contains a SIP Uniform Resource Identifier (URI) or SIPS(secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy. These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp".When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only aRecord-Route rewriting solution.

RFC 5659 An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge

Authors: M. Bocci, S. Bryant.

Date: October 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5659

This document describes an architecture for extending pseudowire emulation across multiple packet switched network (PSN) segments.Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, as are other scenarios where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi- segment pseudowires, defines terminology, and specifies the various protocol elements and their functions.

RFC 5660 IPsec Channels: Connection Latching

Authors: N. Williams.

Date: October 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5660

This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec SecurityAssociation (SA) parameters for the lifetime of the connections.Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.
Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than NothingSecurity (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.
Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels.

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 5662 Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description

Authors: S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed..

Date: January 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5662

This document provides the External Data Representation Standard(XDR) description for Network File System version 4 (NFSv4) minor version 1.

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 5664 Object-Based Parallel NFS (pNFS) Operations

Authors: B. Halevy, B. Welch, J. Zelenka.

Date: January 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5664

Parallel NFS (pNFS) extends Network File System 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, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification.

RFC 5665 IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats

Authors: M. Eisler.

Date: January 2010

Formats: txt json html

Updates: RFC 1833

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5665

This document lists IANA Considerations for Remote Procedure Call(RPC) Network Identifiers (netids) and RPC Universal NetworkAddresses (uaddrs). This document updates, but does not replace, RFC1833.

RFC 5666 Remote Direct Memory Access Transport for Remote Procedure Call

Authors: T. Talpey, B. Callaghan.

Date: January 2010

Formats: txt html json

Obsoleted by: RFC 8166

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5666

This document describes a protocol providing Remote Direct MemoryAccess (RDMA) as a new transport for Remote Procedure Call (RPC).The RDMA transport binding conveys the benefits of efficient, bulk- data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself.

RFC 5667 Network File System (NFS) Direct Data Placement

Authors: T. Talpey, B. Callaghan.

Date: January 2010

Formats: txt html json

Obsoleted by: RFC 8267

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5667

This document defines the bindings of the various Network File System(NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2,3, 4, and 4.1 over such an RDMA transport.

RFC 5668 4-Octet AS Specific BGP Extended Community

Authors: Y. Rekhter, S. Sangli, D. Tappan.

Date: October 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5668

This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number.

RFC 5669 The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)

Authors: S. Yoon, J. Kim, H. Park, H. Jeong, Y. Won.

Date: August 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5669

This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport ControlProtocol (RTCP).

RFC 5670 Metering and Marking Behaviour of PCN-Nodes

Authors: P. Eardley, Ed..

Date: November 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5670

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allowsPCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows.

RFC 5671 Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)

Authors: S. Yasukawa, A. Farrel, Ed..

Date: October 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5671

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) networks.
Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered(TE) Label Switched Paths (LSPs).
This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate.

RFC 5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update

Authors: D. Crocker, Ed..

Date: August 2009

Formats: txt html json

Obsoleted by: RFC 6376

Updates: RFC 4871

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5672

This document updates RFC 4871, "DomainKeys Identified Mail (DKIM)Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module.The Update is in the style of an Errata entry, albeit a rather long one.

RFC 5673 Industrial Routing Requirements in Low-Power and Lossy Networks

Authors: K. Pister, Ed., P. Thubert, Ed., S. Dwars, T. Phinney.

Date: October 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5673

The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices.

RFC 5674 Alarms in Syslog

Authors: S. Chisholm, R. Gerhards.

Date: October 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5674

This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. It also includes a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB.

RFC 5675 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages

Authors: V. Marinov, J. Schoenwaelder.

Date: October 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5675

This memo defines a mapping from Simple Network Management Protocol(SNMP) notifications to SYSLOG messages.

RFC 5676 Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications

Authors: J. Schoenwaelder, A. Clemm, A. Karmakar.

Date: October 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5676

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 mapping of SYSLOG messages to SimpleNetwork Management Protocol (SNMP) notifications.

RFC 5677 IEEE 802.21 Mobility Services Framework Design (MSFD)

Authors: T. Melia, Ed., G. Bajko, S. Das, N. Golmie, JC. Zuniga.

Date: December 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5677

This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for MobilityServices (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server. Instead, it is assumed that either lower- layer (e.g., link-layer) security mechanisms or overall system- specific proprietary security solutions are used.

RFC 5678 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery

Authors: G. Bajko, S. Das.

Date: December 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5678

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS) (see RFC 5677). These Mobility Services are used to assist a mobile node (MN) in handover preparation(network discovery) and handover decision (network selection). The services addressed in this document are the Media IndependentHandover Services defined in IEEE 802.21.

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 5680 The Nominating Committee Process: Open Disclosure of Willing Nominees

Authors: S. Dawkins, Ed..

Date: October 2009

Formats: txt json html

Obsoleted by: RFC 7437

Updates: RFC 3777

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5680

This document updates RFC 3777, Section 3, Bullet 6 to allow aNominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling.

RFC 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 5682 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP

Authors: P. Sarolahti, M. Kojo, K. Yamamoto, M. Hata.

Date: September 2009

Formats: txt html json

Updates: RFC 4138

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5682

The purpose of this document is to move the F-RTO (ForwardRTO-Recovery) functionality for TCP in RFC 4138 fromExperimental to Standards Track status. The F-RTO support for StreamControl Transmission Protocol (SCTP) in RFC 4138 remains withExperimental status. See Appendix B for the differences between this document and 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.

RFC 5683 Password-Authenticated Key (PAK) Diffie-Hellman Exchange

Authors: A. Brusilovsky, I. Faynberg, Z. Zeltsan, S. Patel.

Date: February 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5683

This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called the Password-Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange.
The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy.

RFC 5684 Unintended Consequences of NAT Deployments with Overlapping Address Space

Authors: P. Srisuresh, B. Ford.

Date: February 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5684

This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using NetworkAddress Translator (NAT) devices. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces.Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks(VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown.

RFC 5685 Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: V. Devarapalli, K. Weniger.

Date: November 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5685

The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent.

RFC 5686 RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec

Authors: Y. Hiwasaki, H. Ohmuro.

Date: October 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5686

This document describes the RTP payload format of a mU-law EMbeddedCoder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech.

RFC 5687 GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements

Authors: H. Tschofenig, H. Schulzrinne.

Date: March 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5687

This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) LocationConfiguration Protocol (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from aLocation Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation (LoST) Protocol or to convey location within the Session Initiation Protocol (SIP) to other entities.

RFC 5688 A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes

Authors: J. Rosenberg.

Date: January 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5688

The caller preferences specification for the Session InitiationProtocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities.Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and it provides insufficient granularity as a capability. This specification allows a UA to indicate which application subtypes the agent supports.

RFC 5689 Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)

Authors: C. Daboo.

Date: September 2009

Formats: txt json html

Updates: RFC 4791, RFC 4918

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5689

This specification extends the Web Distributed Authoring andVersioning (WebDAV) MKCOL (Make Collection) method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time.

RFC 5690 Adding Acknowledgement Congestion Control to TCP

Authors: S. Floyd, A. Arcia, D. Ros, J. Iyengar.

Date: February 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5690

This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and theTCP data receiver. The TCP data sender detects lost or ExplicitCongestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's)Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community.

RFC 5691 RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio

Authors: F. de Bont, S. Doehla, M. Schmidt, R. Sperschneider.

Date: October 2009

Formats: txt json html

Updates: RFC 3640

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5691

This memo describes extensions for the RTP payload format defined inRFC 3640 for the transport of MPEG Surround multi-channel audio.Additional Media Type parameters are defined to signal backwards- compatible transmission inside an MPEG-4 Audio elementary stream. In addition, a layered transmission scheme that doesn't use the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data.

RFC 5692 Transmission of IP over Ethernet over IEEE 802.16 Networks

Authors: H. Jeon, S. Jeong, M. Riegel.

Date: October 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5692

This document describes the transmission of IPv4 over Ethernet, as well as IPv6 over Ethernet, in an access network deploying the IEEE802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections that IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control(MAC) functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP-specific support functions in the Ethernet overIEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior.

RFC 5693 Application-Layer Traffic Optimization (ALTO) Problem Statement

Authors: J. Seedorf, E. Burger.

Date: October 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5693

Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.
This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection.

RFC 5694 Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability

Authors: G. Camarillo, Ed., IAB.

Date: November 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5694

In this document, we provide a survey of P2P (Peer-to-Peer) systems.The survey includes a definition and several taxonomies of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural trade-offs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application.

RFC 5695 MPLS Forwarding Benchmarking Methodology for IP Flows

Authors: A. Akhter, R. Asati, C. Pignataro.

Date: November 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5695

This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows. It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF BenchmarkingMethodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm.

RFC 5696 Baseline Encoding and Transport of Pre-Congestion Information

Authors: T. Moncaster, B. Briscoe, M. Menth.

Date: November 2009

Formats: txt html json

Obsoleted by: RFC 6660

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5696

The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging toPCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity.

RFC 5697 Other Certificates Extension

Authors: S. Farrell.

Date: November 2009

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5697

Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit.

RFC 5698 Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)

Authors: T. Kunz, S. Okunick, U. Pordesch.

Date: November 2009

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5698

Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time, which may be in the past, the present, or the future.

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 5703 Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure

Authors: T. Hansen, C. Daboo.

Date: October 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5703

This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message.

RFC 5704 Uncoordinated Protocol Development Considered Harmful

Authors: S. Bryant, Ed., M. Morrow, Ed., IAB.

Date: November 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5704

This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.
This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team onMPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETFRFCs.
Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF.

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 5706 Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions

Authors: D. Harrington.

Date: November 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5706

New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal.The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered.

RFC 5707 Media Server Markup Language (MSML)

Authors: A. Saleem, Y. Xin, G. Sharratt.

Date: February 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5707

The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants usingVoiceXML.

RFC 5708 X.509 Key and Signature Encoding for the KeyNote Trust Management System

Authors: A. Keromytis.

Date: January 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5708

This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer orLicensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication.
In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792).

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 5710 PathErr Message Triggered MPLS and GMPLS LSP Reroutes

Authors: L. Berger, D. Papadimitriou, JP. Vasseur.

Date: January 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5710

This document describes how Resource ReserVation Protocol (RSVP)PathErr messages may be used to trigger rerouting of Multi-ProtocolLabel Switching (MPLS) and Generalized MPLS (GMPLS) point-to-pointTraffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown. This document describes the usage of existingStandards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values.

RFC 5711 Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages

Authors: JP. Vasseur, Ed., G. Swallow, I. Minei.

Date: January 2010

Formats: txt json html

Updates: RFC 3209

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5711

The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource ReservationProtocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS(GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions.

RFC 5712 MPLS Traffic Engineering Soft Preemption

Authors: M. Meyer, Ed., JP. Vasseur, Ed..

Date: January 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5712

This document specifies Multiprotocol Label Switching (MPLS) TrafficEngineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering LabelSwitched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until theTE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities.

RFC 5713 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)

Authors: H. Moustafa, H. Tschofenig, S. De Cnodder.

Date: January 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5713

The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line AccessMultiplexer (DSLAM)). The main goal of this protocol is to allow theNAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS.
This present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model forANCP security, with the aim of deciding which security functions are required. Based on this, security requirements regarding the AccessNode Control Protocol are defined.

RFC 5714 IP Fast Reroute Framework

Authors: M. Shand, S. Bryant.

Date: January 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5714

This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding.

RFC 5715 A Framework for Loop-Free Convergence

Authors: M. Shand, S. Bryant.

Date: January 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5715

A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.
This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable.

RFC 5716 Requirements for Federated File Systems

Authors: J. Lentini, C. Everhart, D. Ellard, R. Tewari, M. Naik.

Date: January 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5716

This document describes and lists the functional requirements of a federated file system and defines related terms.

RFC 5717 Partial Lock Remote Procedure Call (RPC) for NETCONF

Authors: B. Lengyel, M. Bjorklund.

Date: December 2009

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5717

The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore.

RFC 5718 An In-Band Data Communication Network For the MPLS Transport Profile

Authors: D. Beller, A. Farrel.

Date: January 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5718

The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label SwitchedPaths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based onMPLS packet switching technology.
This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management CommunicationNetwork (MCN) and a Signaling Communication Network (SCN).Collectively, the MCN and SCN may be referred to as the DataCommunication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node.

RFC 5719 Updated IANA Considerations for Diameter Command Code Allocations

Authors: D. Romascanu, H. Tschofenig.

Date: January 2010

Formats: txt json html

Obsoleted by: RFC 6733

Updates: RFC 3588

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5719

The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.
This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices.

RFC 5720 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)

Authors: F. Templin.

Date: February 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5720

RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term"enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as aMobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. TheRANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence.

RFC 5721 POP3 Support for UTF-8

Authors: R. Gellens, C. Newman.

Date: February 2010

Formats: txt json html

Obsoleted by: RFC 6856

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5721

This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings.

RFC 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 5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption

Authors: Y. Sheffer, H. Tschofenig.

Date: January 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5723

The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved.In remote access situations, the Extensible Authentication Protocol(EAP) is used for authentication, which adds several more round trips and consequently latency.
To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as aVPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment.
In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume anIKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.
A client can reconnect to a gateway from which it was disconnected.The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re- authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided.

RFC 5724 URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)

Authors: E. Wilde, A. Vaha-Sipila.

Date: January 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5724

This memo specifies the Uniform Resource Identifier (URI) scheme"sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device.

RFC 5725 Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)

Authors: A. Begen, D. Hsu, M. Lague.

Date: February 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5725

This document defines a new report block type within the framework ofRTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE)Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied.By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the SessionDescription Protocol (SDP).

RFC 5726 Mobile IPv6 Location Privacy Solutions

Authors: Y. Qiu, F. Zhao, Ed., R. Koodli.

Date: February 2010

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5726

Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the MobileIPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP MobilityOptimizations (MobOpts) Research Group.

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 5728 The SatLabs Group DVB-RCS MIB

Authors: S. Combes, P. Amundsen, M. Lambert, H-P. Lexow.

Date: March 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5728

This document describes the MIB module for the Digital VideoBroadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS.

RFC 5729 Clarifications on the Routing of Diameter Requests Based on the Username and the Realm

Authors: J. Korhonen, Ed., M. Jones, L. Morand, T. Tsou.

Date: December 2009

Formats: txt json html

Updates: RFC 3588

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5729

This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains aNetwork Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms.

RFC 5730 Extensible Provisioning Protocol (EPP)

Authors: S. Hollenbeck.

Date: August 2009

Formats: txt json html

Obsoletes: RFC 4930

Also: STD 0069

Status: INTERNET STANDARD

DOI: 10.17487/RFC 5730

This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930.

RFC 5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping

Authors: S. Hollenbeck.

Date: August 2009

Formats: txt json html

Obsoletes: RFC 4931

Also: STD 0069

Status: INTERNET STANDARD

DOI: 10.17487/RFC 5731

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.This document obsoletes RFC 4931.

RFC 5732 Extensible Provisioning Protocol (EPP) Host Mapping

Authors: S. Hollenbeck.

Date: August 2009

Formats: txt html json

Obsoletes: RFC 4932

Also: STD 0069

Status: INTERNET STANDARD

DOI: 10.17487/RFC 5732

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.This document obsoletes RFC 4932.

RFC 5733 Extensible Provisioning Protocol (EPP) Contact Mapping

Authors: S. Hollenbeck.

Date: August 2009

Formats: txt html json

Obsoletes: RFC 4933

Also: STD 0069

Status: INTERNET STANDARD

DOI: 10.17487/RFC 5733

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933.

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 5736 IANA IPv4 Special Purpose Address Registry

Authors: G. Huston, M. Cotton, L. Vegoda.

Date: January 2010

Formats: txt html json

Obsoleted by: RFC 6890

Status: INFORMATIONAL

DOI: 10.17487/RFC 5736

This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry.

RFC 5737 IPv4 Address Blocks Reserved for Documentation

Authors: J. Arkko, M. Cotton, L. Vegoda.

Date: January 2010

Formats: txt html json

Updates: RFC 1166

Status: INFORMATIONAL

DOI: 10.17487/RFC 5737

Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks.

RFC 5738 IMAP Support for UTF-8

Authors: P. Resnick, C. Newman.

Date: March 2010

Formats: txt json html

Obsoleted by: RFC 6855

Updates: RFC 3501

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5738

This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers.

RFC 5739 IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: P. Eronen, J. Laganier, C. Madson.

Date: February 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5739

When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes forIKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway"virtual link".

RFC 5740 NACK-Oriented Reliable Multicast (NORM) Transport Protocol

Authors: B. Adamson, C. Bormann, M. Handley, J. Macker.

Date: November 2009

Formats: txt html json

Obsoletes: RFC 3940

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5740

This document describes the messages and procedures of the Negative-ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol(TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity(possibly a unicast return path) between the senders and receivers.The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETFReliable Multicast Transport (RMT) building blocks in its design.This document obsoletes RFC 3940.

RFC 5741 RFC Streams, Headers, and Boilerplates

Authors: L. Daigle, Ed., O. Kolkman, Ed., IAB.

Date: December 2009

Formats: txt html json

Obsoleted by: RFC 7841

Updates: RFC 2223, RFC 4844

Status: INFORMATIONAL

DOI: 10.17487/RFC 5741

RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review.

RFC 5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions

Authors: H. Alvestrand, R. Housley.

Date: December 2009

Formats: txt json html

Obsoletes: RFC 3932

Updates: RFC 2026, RFC 3710

Also: BCP 0092

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5742

This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the IndependentSubmission and IRTF streams.
This document updates procedures described in RFC 2026 and RFC 3710.

RFC 5743 Definition of an Internet Research Task Force (IRTF) Document Stream

Authors: A. Falk.

Date: December 2009

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5743

This memo defines the publication stream for RFCs from the InternetResearch Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor.

RFC 5744 Procedures for Rights Handling in the RFC Independent Submission Stream

Authors: R. Braden, J. Halpern.

Date: December 2009

Formats: txt html json

Updates: RFC 4846

Status: INFORMATIONAL

DOI: 10.17487/RFC 5744

This document specifies the procedures by which authors of RFCIndependent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the"outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result.

RFC 5745 Procedures for Rights Handling in the RFC IAB Stream

Authors: A. Malis, Ed., IAB.

Date: December 2009

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5745

RFC 5746 Transport Layer Security (TLS) Renegotiation Indication Extension

Authors: E. Rescorla, M. Ray, S. Dispensa, N. Oskov.

Date: February 2010

Formats: txt json html

Updates: RFC 5246, RFC 4366, RFC 4347, RFC 4346, RFC 2246

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5746

Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack.

RFC 5747 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions

Authors: J. Wu, Y. Cui, X. Li, M. Xu, C. Metz.

Date: March 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5747

The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China.

RFC 5748 IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)

Authors: S. Yoon, J. Jeong, H. Kim, H. Jeong, Y. Won.

Date: August 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5748

This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) inMultimedia Internet KEYing (MIKEY).

RFC 5749 Distribution of EAP-Based Keys for Handover and Re-Authentication

Authors: K. Hoeper, Ed., M. Nakhjiri, Y. Ohba, Ed..

Date: March 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5749

This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an ExtendedMaster Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication,Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used.

RFC 5750 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling

Authors: B. Ramsdell, S. Turner.

Date: January 2010

Formats: txt html json

Obsoletes: RFC 3850

Obsoleted by: RFC 8550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5750

This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents.S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing.S/MIME agents validate certificates as described in RFC 5280, theInternet X.509 Public Key Infrastructure Certificate and CRL Profile.S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletesRFC 3850.

RFC 5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification

Authors: B. Ramsdell, S. Turner.

Date: January 2010

Formats: txt html json

Obsoletes: RFC 3851

Obsoleted by: RFC 8551

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5751

This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851.

RFC 5752 Multiple Signatures in Cryptographic Message Syntax (CMS)

Authors: S. Turner, J. Schaad.

Date: January 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5752

Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than oneSignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration.

RFC 5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)

Authors: S. Turner, D. Brown.

Date: January 2010

Formats: txt json html

Obsoletes: RFC 3278

Status: INFORMATIONAL

DOI: 10.17487/RFC 5753

This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). TheECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC3370 and RFC 3565 for key wrap and content encryption, NIST FIPS180-3 for message digest, SEC1 for key derivation, and RFC 2104 andRFC 4231 for message authentication code standards. This document obsoletes RFC 3278.

RFC 5754 Using SHA2 Algorithms with Cryptographic Message Syntax

Authors: S. Turner.

Date: January 2010

Formats: txt html json

Updates: RFC 3370

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5754

This document describes the conventions for using the Secure HashAlgorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384,SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm.

RFC 5755 An Internet Attribute Certificate Profile for Authorization

Authors: S. Farrell, R. Housley, S. Turner.

Date: January 2010

Formats: txt html json

Obsoletes: RFC 3281

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5755

This specification defines a profile for the use of X.509 AttributeCertificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281.

RFC 5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters

Authors: S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk.

Date: January 2010

Formats: txt json html

Updates: RFC 4055

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5756

This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding(RSAES-OAEP) key transport algorithm in the Internet X.509 Public KeyInfrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field.

RFC 5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey

Authors: T. Schmidt, M. Waehlisch, G. Fairhurst.

Date: February 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5757

This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast andSource-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized.Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.

RFC 5758 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA

Authors: Q. Dang, S. Santesson, K. Moriarty, D. Brown, T. Polk.

Date: January 2010

Formats: txt html json

Updates: RFC 3279

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5758

This document updates RFC 3279 to specify algorithm identifiers andASN.1 encoding rules for the Digital Signature Algorithm (DSA) andElliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 PublicKey infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the InternetX.509 PKI.

RFC 5759 Suite B Certificate and Certificate Revocation List (CRL) Profile

Authors: J. Solinas, L. Zieglar.

Date: January 2010

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 5759

This document specifies a base profile for X.509 v3 Certificates andX.509 v2 Certificate Revocation Lists (CRLs) for use with the UnitedStates National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 PublicKey Infrastructure Certificate and Certificate Revocation List (CRL)Profile".

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 5765 Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications

Authors: H. Schulzrinne, E. Marocco, E. Ivov.

Date: February 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5765

Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P-specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2PResearch Group.

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 5767 User-Agent-Driven Privacy Mechanism for SIP

Authors: M. Munakata, S. Schubert, T. Ohba.

Date: April 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5767

This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) andTraversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323.

RFC 5768 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)

Authors: J. Rosenberg.

Date: April 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5768

This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE. The option tag allows a UA to require support for ICE in order for a call to proceed.

RFC 5769 Test Vectors for Session Traversal Utilities for NAT (STUN)

Authors: R. Denis-Courmont.

Date: April 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5769

The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these --FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes.

RFC 5770 Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators

Authors: M. Komu, T. Henderson, H. Tschofenig, J. Melen, A. Keranen, Ed..

Date: April 2010

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5770

This document specifies extensions to the Host Identity Protocol(HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive ConnectivityEstablishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulatingEncapsulating Security Payload (ESP) packets within the User DatagramProtocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server.With these extensions HIP is able to work in environments that haveNATs and provides a generic NAT traversal solution to higher-layer networking applications.

RFC 5771 IANA Guidelines for IPv4 Multicast Address Assignments

Authors: M. Cotton, L. Vegoda, D. Meyer.

Date: March 2010

Formats: txt html json

Obsoletes: RFC 3138, RFC 3171

Updates: RFC 2780

Also: BCP 0051

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5771

This document provides guidance for the Internet Assigned NumbersAuthority (IANA) in assigning IPv4 multicast addresses. It obsoletesRFC 3171 and RFC 3138 and updates RFC 2780.

RFC 5772 A Set of Possible Requirements for a Future Routing Architecture

Authors: A. Doria, E. Davies, F. Kastenholz.

Date: February 2010

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 5772

The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group(RRG) in 2001, with some editorial updates up to 2006. The two sub- groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for theInternet in the future.
The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication.

RFC 5773 Analysis of Inter-Domain Routing Requirements and History

Authors: E. Davies, A. Doria.

Date: February 2010

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 5773

This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to"A Set of Possible Requirements for a Future Routing Architecture"(RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication.

RFC 5774 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition

Authors: K. Wolf, A. Mayrhofer.

Date: March 2010

Formats: txt html json

Updates: RFC 4776

Also: BCP 0154

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5774

This document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC4776. Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria.

RFC 5775 Asynchronous Layered Coding (ALC) Protocol Instantiation

Authors: M. Luby, M. Watson, L. Vicisano.

Date: April 2010

Formats: txt html json

Obsoletes: RFC 3450

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5775

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.Asynchronous Layered Coding combines the Layered Coding Transport(LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450.

RFC 5776 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols

Authors: V. Roca, A. Francillon, S. Faurite.

Date: April 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5776

This document details the Timed Efficient Stream Loss-TolerantAuthentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within theAsynchronous Layered Coding (ALC) and NACK-Oriented ReliableMulticast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document.

RFC 5777 Traffic Classification and Quality of Service (QoS) Attributes for Diameter

Authors: J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior.

Date: February 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5777

This document defines a number of Diameter attribute-value pairs(AVPs) for traffic classification with actions for filtering andQuality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by theAugmented Backus-Naur Form (ABNF) specification of the respectiveDiameter command extension policy.

RFC 5778 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction

Authors: J. Korhonen, Ed., H. Tschofenig, J. Bournelle, G. Giaretta, M. Nakhjiri.

Date: February 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5778

Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and theDiameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and aDiameter server.
This document defines the home agent to the Diameter server communication when the mobile node authenticates using the InternetKey Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document.

RFC 5779 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server

Authors: J. Korhonen, Ed., J. Bournelle, K. Chowdhury, A. Muhanna, U. Meyer.

Date: February 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5779

This specification defines Authentication, Authorization, andAccounting (AAA) interactions between Proxy Mobile IPv6 entities(both Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a Proxy Mobile IPv6 Domain. These AAA interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store.

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 5781 The rsync URI Scheme

Authors: S. Weiler, D. Ward, R. Housley.

Date: February 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5781

This document specifies the rsync Uniform Resource Identifier (URI) scheme.

RFC 5782 DNS Blacklists and Whitelists

Authors: J. Levine.

Date: February 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5782

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them.

RFC 5783 Congestion Control in the RFC Series

Authors: M. Welzl, W. Eddy.

Date: February 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5783

This document is an informational snapshot taken by the IRTF'sInternet Congestion Control Research Group (ICCRG) in October 2008.It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards.

RFC 5784 Sieve Email Filtering: Sieves and Display Directives in XML

Authors: N. Freed, S. Vedam.

Date: March 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5784

This document describes a way to represent Sieve email filtering language scripts in XML. Representing Sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools.
The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format.

RFC 5785 Defining Well-Known Uniform Resource Identifiers (URIs)

Authors: M. Nottingham, E. Hammer-Lahav.

Date: April 2010

Formats: txt html json

Obsoleted by: RFC 8615

Updates: RFC 2616, RFC 2818

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5785

This memo defines a path prefix for "well-known locations","/.well-known/", in selected Uniform Resource Identifier (URI) schemes.

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 5787 OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing

Authors: D. Papadimitriou.

Date: March 2010

Formats: txt json html

Obsoleted by: RFC 6827

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5787

The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical TransportNetworks (OTNs), and lambda switching optical networks.
The requirements for GMPLS routing to satisfy the requirements ofASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.
Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision ofRFC 4258.

RFC 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 5789 PATCH Method for HTTP

Authors: L. Dusseault, J. Snell.

Date: March 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5789

Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existingHTTP PUT method only allows a complete replacement of a document.This proposal adds a new HTTP method, PATCH, to modify an existingHTTP resource.

RFC 5790 Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols

Authors: H. Liu, W. Cao, H. Asaeda.

Date: February 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5790

This document describes lightweight IGMPv3 and MLDv2 protocols (LW-IGMPv3 and LW-MLDv2), which simplify the standard (full) versions ofIGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account.

RFC 5791 RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete

Authors: J. Reschke, J. Kunze.

Date: February 2010

Formats: txt html json

Obsoletes: RFC 2731

Status: INFORMATIONAL

DOI: 10.17487/RFC 5791

This document obsoletes RFC 2731, "Encoding Dublin Core Metadata inHTML", as further development of this specification has moved to theDublin Core Metadata Initiative (DCMI).

RFC 5792 PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)

Authors: P. Sangster, K. Narayan.

Date: March 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5792

This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification.

RFC 5793 PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)

Authors: R. Sahita, S. Hanna, R. Hurst, K. Narayan.

Date: March 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5793

This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEARequirements specification.

RFC 5794 A Description of the ARIA Encryption Algorithm

Authors: J. Lee, J. Lee, J. Kim, D. Kwon, C. Kim.

Date: March 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5794

This document describes the ARIA encryption algorithm. ARIA is a128-bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of a key scheduling part and data randomizing part.

RFC 5795 The RObust Header Compression (ROHC) Framework

Authors: K. Sandlund, G. Pelletier, L-E. Jonsson.

Date: March 2010

Formats: txt html json

Obsoletes: RFC 4995

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5795

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.
This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications.

RFC 5796 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages

Authors: W. Atwood, S. Islam, M. Siami.

Date: March 2010

Formats: txt json html

Updates: RFC 4601

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5796

RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - SparseMode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security(IPsec) Encapsulating Security Payload (ESP) or (optionally) theAuthentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601.

RFC 5797 FTP Command and Extension Registry

Authors: J. Klensin, A. Hoenes.

Date: March 2010

Formats: txt json html

Updates: RFC 0959

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5797

Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both those supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command andFeature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry.

RFC 5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6

Authors: S. Nadas, Ed..

Date: March 2010

Formats: txt html json

Obsoletes: RFC 3768

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5798

This memo defines the Virtual Router Redundancy Protocol (VRRP) forIPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in"Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to theseIPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. ForIPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6Neighbor Discovery mechanisms.

RFC 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 5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets

Authors: A. Melnikov.

Date: July 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5803

This memo describes how the "authPassword" Lightweight DirectoryAccess Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Message (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework.

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 5805 Lightweight Directory Access Protocol (LDAP) Transactions

Authors: K. Zeilenga.

Date: March 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5805

Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction.Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions.

RFC 5806 Diversion Indication in SIP

Authors: S. Levy, M. Mohali, Ed..

Date: March 2010

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 5806

This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for laterInformational RFCs. The original Abstract follows.
This document proposes an extension to the Session InitiationProtocol (SIP). This extension provides the ability for the calledSIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header,Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent.
This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and AutomaticCall Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions.

RFC 5807 Definition of Master Key between PANA Client and Enforcement Point

Authors: Y. Ohba, A. Yegin.

Date: March 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5807

This document defines a master key used between a client of theProtocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of the ExtensibleAuthentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families.

RFC 5808 Requirements for a Location-by-Reference Mechanism

Authors: R. Marshall, Ed..

Date: May 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5808

This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location UniformResource Identifier (URI) to handle location information within signaling and other Internet messaging.

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 5811 SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol

Authors: J. Hadi Salim, K. Ogawa.

Date: March 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5811

This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol.It explains the rationale for choosing the SCTP (Stream ControlTransmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol.

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 5813 Forwarding and Control Element Separation (ForCES) MIB

Authors: R. Haas.

Date: March 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5813

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and ControlElement Separation (ForCES) Network Element (NE).

RFC 5814 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks

Authors: W. Sun, Ed., G. Zhang, Ed..

Date: March 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5814

Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for a future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches,Dense Wavelength Division Multiplexing (DWDM) systems, Add-DropMultiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other.
This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance inGMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning.

RFC 5815 Definitions of Managed Objects for IP Flow Information Export

Authors: T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz.

Date: April 2010

Formats: txt json html

Obsoleted by: RFC 6615

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5815

This document defines managed objects for IP Flow Information eXport(IPFIX). These objects provide information for monitoring IPFIXExporters and IPFIX Collectors including the basic configuration information.

RFC 5816 ESSCertIDv2 Update for RFC 3161

Authors: S. Santesson, N. Pope.

Date: April 2010

Formats: txt html json

Updates: RFC 3161

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5816

This document updates RFC 3161. It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure HashAlgorithm (SHA-1).

RFC 5817 Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks

Authors: Z. Ali, JP. Vasseur, A. Zamfir, J. Newton.

Date: April 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5817

MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network.
This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to bothMPLS-TE and its Generalized MPLS (GMPLS) extensions.

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 5819 IMAP4 Extension for Returning STATUS Information in Extended LIST

Authors: A. Melnikov, T. Sirainen.

Date: March 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5819

Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by theLIST command.

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 5824 Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN

Authors: K. Kumaki, Ed., R. Zhang, Y. Kamite.

Date: April 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5824

Today, customers expect to run triple-play services through BGP/MPLSIP-VPNs. Some service providers will deploy services that requestQuality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application(e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase.
Service providers can use both an MPLS and an MPLS TrafficEngineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) andRSVP-TE over a BGP/MPLS IP-VPN.

RFC 5825 Displaying Downgraded Messages for Email Address Internationalization

Authors: K. Fujiwara, B. Leiba.

Date: April 2010

Formats: txt json html

Obsoleted by: RFC 6530

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5825

This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields.

RFC 5826 Home Automation Routing Requirements in Low-Power and Lossy Networks

Authors: A. Brandt, J. Buron, G. Porcu.

Date: April 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5826

This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks. In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio- frequency-based AV remote control, central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment.

RFC 5827 Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)

Authors: M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton, P. Hurtig.

Date: May 2010

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5827

This document proposes a new mechanism for TCP and Stream ControlTransmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "EarlyRetransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout.

RFC 5828 Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework

Authors: D. Fedyk, L. Berger, L. Andersson.

Date: March 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5828

There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into"transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET) /Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing(TDM), and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized-MPLS-based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions.

RFC 5829 Link Relation Types for Simple Version Navigation between Web Resources

Authors: A. Brown, G. Clemm, J. Reschke, Ed..

Date: April 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5829

This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies.

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 5833 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB

Authors: Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed..

Date: May 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5833

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control AndProvisioning of Wireless Access Points (CAPWAP) Protocol. This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol.

RFC 5834 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11

Authors: Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed..

Date: May 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5834

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for IEEE 802.11 wireless binding. This MIB module is presented as a basis for future work on the management of the CAPWAP protocol using the Simple NetworkManagement Protocol (SNMP).

RFC 5835 Framework for Metric Composition

Authors: A. Morton, Ed., S. Van den Berghe, Ed..

Date: April 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5835

This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by theIETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice.

RFC 5836 Extensible Authentication Protocol (EAP) Early Authentication Problem Statement

Authors: Y. Ohba, Ed., Q. Wu, Ed., G. Zorn, Ed..

Date: April 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5836

Extensible Authentication Protocol (EAP) early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival. This document discusses the EAP early authentication problem in detail.

RFC 5837 Extending ICMP for Interface and Next-Hop Identification

Authors: A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., N. Shen, JR. Rivers.

Date: April 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5837

This memo defines a data structure that can be appended to selectedICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and theIP next hop to which the datagram would have been forwarded.
Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces.

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 5839 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification

Authors: A. Niemi, D. Willis, Ed..

Date: May 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5839

The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed.

RFC 5840 Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility

Authors: K. Grewal, G. Montenegro, M. Bhatia.

Date: April 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5840

This document describes the Wrapped Encapsulating Security Payload(WESP) protocol, which builds on the Encapsulating Security Payload(ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP.

RFC 5841 TCP Option to Denote Packet Mood

Authors: R. Hay, W. Turkal.

Date: 1 April 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5841

This document proposes a new TCP option to denote packet mood.

RFC 5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)

Authors: G. Clemm, J. Crawford, J. Reschke, Ed., J. Whitehead.

Date: April 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5842

This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource.Servers are required to ensure the integrity of any bindings that they allow to be created.

RFC 5843 Additional Hash Algorithms for HTTP Instance Digests

Authors: A. Bryan.

Date: April 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5843

The IANA registry named "Hypertext Transfer Protocol (HTTP) DigestAlgorithm Values" defines values for digest algorithms used byInstance Digests in HTTP. Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource. This document adds new values to the registry and updates previous values.

RFC 5844 IPv4 Support for Proxy Mobile IPv6

Authors: R. Wakikawa, S. Gundavelli.

Date: May 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5844

This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy MobileIPv6 domain to exchange signaling messages over an IPv4 transport network.

RFC 5845 Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6

Authors: A. Muhanna, M. Khalil, S. Gundavelli, K. Leung.

Date: June 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5845

This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiateGeneric Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys.

RFC 5846 Binding Revocation for IPv6 Mobility

Authors: A. Muhanna, M. Khalil, S. Gundavelli, K. Chowdhury, P. Yegani.

Date: June 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5846

This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6. The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified Binding Cache entries.

RFC 5847 Heartbeat Mechanism for Proxy Mobile IPv6

Authors: V. Devarapalli, Ed., R. Koodli, Ed., H. Lim, N. Kant, S. Krishnan, J. Laganier.

Date: June 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5847

Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action.

RFC 5848 Signed Syslog Messages

Authors: J. Kelsey, J. Callas, A. Clemm.

Date: May 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5848

This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages.This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol".

RFC 5849 The OAuth 1.0 Protocol

Authors: E. Hammer-Lahav, Ed..

Date: April 2010

Formats: txt html json

Obsoleted by: RFC 6749

Status: INFORMATIONAL

DOI: 10.17487/RFC 5849

OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third- party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirections.

RFC 5850 A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)

Authors: R. Mahy, R. Sparks, J. Rosenberg, D. Petrie, A. Johnston, Ed..

Date: May 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5850

This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol(SIP). To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history.This framework also describes other goals that embody the spirit ofSIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others.

RFC 5851 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks

Authors: S. Ooghe, N. Voigt, M. Platnic, T. Haag, S. Wadhwa.

Date: May 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5851

The purpose of this document is to define a framework for an AccessNode Control Mechanism between a Network Access Server (NAS) and anAccess Node (e.g., a Digital Subscriber Line Access Multiplexer(DSLAM)) in a multi-service reference architecture in order to perform operations related to service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems.
This document first identifies a number of use cases for which theAccess Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to supportANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements.

RFC 5852 RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network

Authors: D. Caviglia, D. Ceccarelli, D. Bramanti, D. Li, S. Bardalai.

Date: April 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5852

In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) ControlPlane (Soft Permanent Connections - SPC) or a Management System(Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493.
This memo describes an extension to GMPLS Resource ReservationProtocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and theControl Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection.

RFC 5853 Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments

Authors: J. Hautakorpi, Ed., G. Camarillo, R. Penfield, A. Hawrylyshen, M. Bhatia.

Date: April 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5853

This document describes functions implemented in Session InitiationProtocol (SIP) intermediaries known as Session Border Controllers(SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required.

RFC 5854 The Metalink Download Description Format

Authors: A. Bryan, T. Tsujikawa, N. McNab, P. Poeml.

Date: June 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5854

This document specifies Metalink, an XML-based download description format. Metalink describes download locations (mirrors), cryptographic hashes, and other information. Clients can transparently use this information to reliably transfer files.

RFC 5855 Nameservers for IPv4 and IPv6 Reverse Zones

Authors: J. Abley, T. Manderson.

Date: May 2010

Formats: txt html json

Also: BCP 0155

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 5855

This document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These zones contain data that facilitate reverse mapping (address to name).

RFC 5856 Integration of Robust Header Compression over IPsec Security Associations

Authors: E. Ertekin, R. Jasani, C. Christou, C. Bormann.

Date: May 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5856

IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec).By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs).

RFC 5857 IKEv2 Extensions to Support Robust Header Compression over IPsec

Authors: E. Ertekin, C. Christou, R. Jasani, T. Kivinen, C. Bormann.

Date: May 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5857

In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints. Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs).

RFC 5858 IPsec Extensions to Support Robust Header Compression over IPsec

Authors: E. Ertekin, C. Christou, C. Bormann.

Date: May 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5858

Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC withIPsec, extensions to the Security Policy Database (SPD) and SecurityAssociation Database (SAD) are required. This document describes theIPsec extensions required to support ROHCoIPsec.

RFC 5859 TFTP Server Address Option for DHCPv4

Authors: R. Johnson.

Date: June 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5859

This memo documents existing usage for the "TFTP Server Address" option. The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any pre-existing usages of option numbers in the range 128-223 should be documented, and the Dynamic HostConfiguration working group will try to officially assign those numbers to those options. The option is defined for DHCPv4 and works only with IPv4 addresses.

RFC 5860 Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks

Authors: M. Vigoureux, Ed., D. Ward, Ed., M. Betts, Ed..

Date: May 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5860

This document lists architectural and functional requirements for theOperations, Administration, and Maintenance of MPLS TransportProfile. These requirements apply to pseudowires, Label SwitchedPaths, and Sections.

RFC 5861 HTTP Cache-Control Extensions for Stale Content

Authors: M. Nottingham.

Date: May 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5861

This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.

RFC 5862 Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE

Authors: S. Yasukawa, A. Farrel.

Date: June 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5862

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) networks.
Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered(TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.
Generic requirements for a communication protocol between PathComputation Clients (PCCs) and PCEs are presented in RFC 4657, "PathComputation Element (PCE) Communication Protocol GenericRequirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering.

RFC 5863 DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations

Authors: T. Hansen, E. Siegel, P. Hallam-Baker, D. Crocker.

Date: May 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5863

DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages.DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational, and migration considerations for DKIM.

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 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic

Authors: F. Baker, J. Polk, M. Dolly.

Date: May 2010

Formats: txt html json

Updates: RFC 4542, RFC 4594

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5865

This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This traffic class conforms to the ExpeditedForwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the ExpeditedForwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission.

RFC 5866 Diameter Quality-of-Service Application

Authors: D. Sun, Ed., P. McCann, H. Tschofenig, T. Tsou, A. Doria, G. Zorn, Ed..

Date: May 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5866

This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation, namely "Pull" and "Push", are defined.

RFC 5867 Building Automation Routing Requirements in Low-Power and Lossy Networks

Authors: J. Martocci, Ed., P. De Mil, N. Riou, W. Vermeylen.

Date: June 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5867

The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power andLossy Networks (LLNs) in various markets: industrial, commercial(building), home, and urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation.

RFC 5868 Problem Statement on the Cross-Realm Operation of Kerberos

Authors: S. Sakane, K. Kamada, S. Zrelli, M. Ishiyama.

Date: May 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5868

This document provides background information regarding large-scaleKerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC 4120.
This document describes some examples of actual large-scale industrial systems, and lists requirements and restrictions regarding authentication operations in such environments. It also identifies a number of requirements derived from the industrial automation field.Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem ofKerberos cross-realm operations.

RFC 5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF)

Authors: H. Krawczyk, P. Eronen.

Date: May 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5869

This document specifies a simple Hashed Message Authentication Code(HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions.

RFC 5870 A Uniform Resource Identifier for Geographic Locations ('geo' URI)

Authors: A. Mayrhofer, C. Spanring.

Date: June 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5870

This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is the World Geodetic System 1984 (WGS-84).

RFC 5871 IANA Allocation Guidelines for the IPv6 Routing Header

Authors: J. Arkko, S. Bradner.

Date: May 2010

Formats: txt html json

Updates: RFC 2460

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5871

This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header.

RFC 5872 IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)

Authors: J. Arkko, A. Yegin.

Date: May 2010

Formats: txt json html

Updates: RFC 5191

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5872

This document relaxes the IANA rules for the Protocol for CarryingAuthentication for Network Access (PANA).

RFC 5873 Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA)

Authors: Y. Ohba, A. Yegin.

Date: May 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5873

This document defines an extension to the Protocol for CarryingAuthentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move.

RFC 5874 An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources

Authors: J. Rosenberg, J. Urpalainen.

Date: May 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5874

This specification defines a document format that can be used to indicate that a change has occurred in a document managed by theExtensible Markup Language (XML) Configuration Access Protocol(XCAP). This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format. It can report existing element and attribute content when versions of an XCAP server document change. XCAP diff documents can be delivered to diff clients using a number of means, including a Session InitiationProtocol (SIP) event package.

RFC 5875 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package

Authors: J. Urpalainen, D. Willis, Ed..

Date: May 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5875

This document describes an "xcap-diff" SIP (Session InitiationProtocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes toExtensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP Diff format.

RFC 5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP)

Authors: J. Elwell.

Date: April 2010

Formats: txt json html

Updates: RFC 3325

Status: INFORMATIONAL

DOI: 10.17487/RFC 5876

The Session Initiation Protocol (SIP) has a mechanism for conveying the identity of the originator of a request by means of theP-Asserted-Identity and P-Preferred-Identity header fields. These header fields are specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a trusted User Agent Client (UAC), does not specify the use ofP-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields. This document extendsRFC 3325 to cover these situations.

RFC 5877 The application/pkix-attr-cert Media Type for Attribute Certificates

Authors: R. Housley.

Date: May 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5877

This document specifies a MIME media type used to carry a single attribute certificate as defined in RFC 5755.

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 5879 Heuristics for Detecting ESP-NULL Packets

Authors: T. Kivinen, D. McDonald.

Date: May 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5879

This document describes a set of heuristics for distinguishing IPsecESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep-inspection engines, to quickly decide whether or not a given packet flow is encrypted, i.e., whether or not it can be inspected. Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303.

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 5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)

Authors: D. Katz, D. Ward.

Date: June 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5881

This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol over IPv4 and IPv6 for single IP hops.

RFC 5882 Generic Application of Bidirectional Forwarding Detection (BFD)

Authors: D. Katz, D. Ward.

Date: June 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5882

This document describes the generic application of the BidirectionalForwarding Detection (BFD) protocol.

RFC 5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths

Authors: D. Katz, D. Ward.

Date: June 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5883

This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol over multihop paths, including unidirectional links.

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 5886 A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture

Authors: JP. Vasseur, Ed., JL. Le Roux, Y. Ikejiri.

Date: June 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5886

A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) LabelSwitched Paths (LSPs) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".
In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in thePCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information.

RFC 5887 Renumbering Still Needs Work

Authors: B. Carpenter, R. Atkinson, H. Flinck.

Date: May 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5887

This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally, there is a gap analysis identifying possible areas for future work.

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 5889 IP Addressing Model in Ad Hoc Networks

Authors: E. Baccelli, Ed., M. Townsley, Ed..

Date: September 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5889

This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties.

RFC 5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework

Authors: J. Klensin.

Date: August 2010

Formats: txt html json

Obsoletes: RFC 3490

Updates: RFC 4343

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5890

This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized DomainNames for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set.

RFC 5891 Internationalized Domain Names in Applications (IDNA): Protocol

Authors: J. Klensin.

Date: August 2010

Formats: txt html json

Obsoletes: RFC 3490, RFC 3491

Updates: RFC 3492

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5891

This document is the revised protocol definition forInternationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names inApplications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text.

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 5893 Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)

Authors: H. Alvestrand, Ed., C. Karp.

Date: August 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5893

The use of right-to-left scripts in Internationalized Domain Names(IDNs) has presented several challenges. This memo provides a newBidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion.

RFC 5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale

Authors: J. Klensin.

Date: August 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5894

Several years have passed since the original protocol forInternationalized Domain Names (IDNs) was completed and deployed.During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components.

RFC 5895 Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008

Authors: P. Resnick, P. Hoffman.

Date: September 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5895

In the original version of the Internationalized Domain Names inApplications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS).The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of"permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol.

RFC 5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy

Authors: L. Hornquist Astrand, S. Hartman.

Date: June 2010

Formats: txt json html

Updates: RFC 2743, RFC 2744, RFC 4120, RFC 4121

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5896

Several Generic Security Service Application Program Interface(GSS-API) applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers, includingCIFS (Common Internet File System) file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC2743).

RFC 5897 Identification of Communications Services in the Session Initiation Protocol (SIP)

Authors: J. Rosenberg.

Date: June 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5897

This document considers the problem of service identification in theSession Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA). This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation. It then outlines a set of recommended practices for service identification.

RFC 5898 Connectivity Preconditions for Session Description Protocol (SDP) Media Streams

Authors: F. Andreasen, G. Camarillo, D. Oran, D. Wing.

Date: July 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5898

This document defines a new connectivity precondition for the SessionDescription Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such asTCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation.

RFC 5901 Extensions to the IODEF-Document Class for Reporting Phishing

Authors: P. Cain, D. Jevans.

Date: July 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5901

This document extends the Incident Object Description Exchange Format(IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents.

RFC 5902 IAB Thoughts on IPv6 Network Address Translation

Authors: D. Thaler, L. Zhang, G. Lebovitz.

Date: July 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5902

There has been much recent discussion on the topic of whether theIETF should develop standards for IPv6 Network Address Translators(NATs). This document articulates the architectural issues raised byIPv6 NATs, the pros and cons of having IPv6 NATs, and provides theIAB's thoughts on the current open issues and the solution space.

RFC 5903 Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2

Authors: D. Fu, J. Solinas.

Date: June 2010

Formats: txt json html

Obsoletes: RFC 4753

Status: INFORMATIONAL

DOI: 10.17487/RFC 5903

This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet KeyExchange version 2 (IKEv2) protocols in addition to previously defined groups. These groups are based on modular arithmetic rather than binary arithmetic. These groups are defined to align IKE andIKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This document obsoletes RFC 4753.

RFC 5904 RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support

Authors: G. Zorn.

Date: June 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5904

This document defines a set of Remote Authentication Dial-In UserService (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1.

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 5906 Network Time Protocol Version 4: Autokey Specification

Authors: B. Haberman, Ed., D. Mills.

Date: June 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5906

This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition,Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.
This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual MemorySystem (VMS) operating systems at http://www.ntp.org.

RFC 5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)

Authors: H. Gerstung, C. Elliott, B. Haberman, Ed..

Date: June 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5907

The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment. As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent. This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort.

RFC 5908 Network Time Protocol (NTP) Server Option for DHCPv6

Authors: R. Gayraud, B. Lourdelet.

Date: June 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5908

The NTP Server Option for Dynamic Host Configuration Protocol forIPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts.

RFC 5909 Securing Neighbor Discovery Proxy: Problem Statement

Authors: J-M. Combes, S. Krishnan, G. Daley.

Date: July 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5909

Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.
Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a MobileNode is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.
Neighbor Discovery Proxy currently cannot be secured using SecureNeighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND.

RFC 5910 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

Authors: J. Gould, S. Hollenbeck.

Date: May 2010

Formats: txt html json

Obsoletes: RFC 4310

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5910

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain NameSystem security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310.

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 5913 Clearance Attribute and Authority Clearance Constraints Certificate Extension

Authors: S. Turner, S. Chokhani.

Date: June 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5913

This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate.The Authority Clearance Constraints certificate extension values in aTrust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject.

RFC 5914 Trust Anchor Format

Authors: R. Housley, S. Ashmore, C. Wallace.

Date: June 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5914

This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in TrustAnchor Management Requirements.

RFC 5915 Elliptic Curve Private Key Structure

Authors: S. Turner, D. Brown.

Date: June 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5915

This document specifies the syntax and semantics for conveyingElliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG).

RFC 5916 Device Owner Attribute

Authors: S. Turner.

Date: June 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5916

This document defines the Device Owner attribute. It indicates the entity (e.g., company, organization, department, agency) that owns the device. This attribute may be included in public key certificates and attribute certificates.

RFC 5917 Clearance Sponsor Attribute

Authors: S. Turner.

Date: June 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5917

This document defines the clearance sponsor attribute. It indicates the entity that sponsored (i.e., granted) the clearance. This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute.

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 5919 Signaling LDP Label Advertisement Completion

Authors: R. Asati, P. Mohapatra, E. Chen, B. Thomas.

Date: August 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5919

There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment.

RFC 5920 Security Framework for MPLS and GMPLS Networks

Authors: L. Fang, Ed..

Date: July 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5920

This document provides a security framework for Multiprotocol LabelSwitching (MPLS) and Generalized Multiprotocol Label Switching(GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizesRSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintainingMPLS and GMPLS networks across different domains or differentService Providers.

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 5922 Domain Certificates in the Session Initiation Protocol (SIP)

Authors: V. Gurbani, S. Lawrence, A. Jeffrey.

Date: June 2010

Formats: txt json html

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5922

This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure usingX.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of aSIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates.

RFC 5923 Connection Reuse in the Session Initiation Protocol (SIP)

Authors: V. Gurbani, Ed., R. Mahy, B. Tate.

Date: June 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5923

This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TransportLayer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control TransmissionProtocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP.

RFC 5924 Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates

Authors: S. Lawrence, V. Gurbani.

Date: June 2010

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5924

This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP.

RFC 5925 The TCP Authentication Option

Authors: J. Touch, A. Mankin, R. Bonica.

Date: June 2010

Formats: txt html json

Obsoletes: RFC 2385

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5925

This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a staticMaster Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinatesMKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5.

RFC 5926 Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)

Authors: G. Lebovitz, E. Rescorla.

Date: June 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5926

The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs).

RFC 5927 ICMP Attacks against TCP

Authors: F. Gont.

Date: July 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5927

This document discusses the use of the Internet Control MessageProtocol (ICMP) to perform a variety of attacks against theTransmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues.

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 5930 Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol

Authors: S. Shen, Y. Mao, NSS. Murthy.

Date: July 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5930

This document describes the usage of Advanced Encryption StandardCounter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange.

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 5932 Camellia Cipher Suites for TLS

Authors: A. Kato, M. Kanda, S. Kanno.

Date: June 2010

Formats: txt json html

Obsoletes: RFC 4132

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5932

This document specifies a set of cipher suites for the TransportSecurity Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the cipher suites originally specified in RFC 4132 by introducing counterparts using the newer cryptographic hash algorithms from the SHA-2 family. This document obsoletes RFC 4132.

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 5934 Trust Anchor Management Protocol (TAMP)

Authors: R. Housley, S. Ashmore, C. Wallace.

Date: August 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5934

This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store. The protocol makes use of the CryptographicMessage Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects.

RFC 5935 Expressing SNMP SMI Datatypes in XML Schema Definition Language

Authors: M. Ellison, B. Natale.

Date: August 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5935

This memo defines the IETF standard expression of Structure ofManagement Information (SMI) base datatypes in XML Schema Definition(XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism.

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 5937 Using Trust Anchor Constraints during Certification Path Processing

Authors: S. Ashmore, C. Wallace.

Date: August 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5937

This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor.Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor.

RFC 5938 Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)

Authors: A. Morton, M. Chiba.

Date: August 2010

Formats: txt html json

Updates: RFC 5357

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5938

The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes anOPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions usingSession Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time.

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 5940 Additional Cryptographic Message Syntax (CMS) Revocation Information Choices

Authors: S. Turner, R. Housley.

Date: August 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5940

The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData,AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the CertificateRevocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol(OCSP) responses and Server-Based Certificate Validation Protocol(SCVP) requests and responses.

RFC 5941 Sharing Transaction Fraud Data

Authors: D. M'Raihi, S. Boeyen, M. Grandcolas, S. Bajaj.

Date: August 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5941

This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling WorkingGroup (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format.

RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes

Authors: H. Singh, W. Beebee, E. Nordmark.

Date: July 2010

Formats: txt html json

Updates: RFC 4861

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5942

IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861.

RFC 5943 A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing

Authors: B. Haberman, Ed..

Date: August 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5943

The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a newRouting Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings).

RFC 5944 IP Mobility Support for IPv4, Revised

Authors: C. Perkins, Ed..

Date: November 2010

Formats: txt json html

Obsoletes: RFC 3344

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5944

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 5945 Resource Reservation Protocol (RSVP) Proxy Approaches

Authors: F. Le Faucheur, J. Manner, D. Wing, A. Guillou.

Date: October 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5945

The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable.This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described.

RFC 5946 Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy

Authors: F. Le Faucheur, J. Manner, A. Narayanan, A. Guillou, H. Malik.

Date: October 2010

Formats: txt html json

Updates: RFC 2205

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5946

Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows.With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP- capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to- end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP ReceiverProxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions.

RFC 5947 Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)

Authors: J. Elwell, H. Kaplan.

Date: September 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5947

This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges(PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers.

RFC 5948 Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16

Authors: S. Madanapalli, S. Park, S. Chakrabarti, G. Montenegro.

Date: August 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5948

IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specificConvergence Sublayers for transmitting upper-layer protocols. ThePacket CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) andIEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 MediaAccess Control (MAC) layer.
This document specifies the frame format, the Maximum TransmissionUnit (MTU), and the address assignment procedures for transmittingIPv4 packets over the IP-specific part of the Packet ConvergenceSublayer of IEEE 802.16.

RFC 5949 Fast Handovers for Proxy Mobile IPv6

Authors: H. Yokota, K. Chowdhury, R. Koodli, B. Patil, F. Xia.

Date: September 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5949

Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. WhileMIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6;RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6.
When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations.

RFC 5950 Network Management Framework for MPLS-based Transport Networks

Authors: S. Mansfield, Ed., E. Gray, Ed., K. Lam, Ed..

Date: September 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5950

This document provides the network management framework for theTransport Profile for Multi-Protocol Label Switching (MPLS-TP).
This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network.
The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system.
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 PWE3 architectures to support the capabilities and functionalities of a packet transport network.

RFC 5951 Network Management Requirements for MPLS-based Transport Networks

Authors: K. Lam, S. Mansfield, E. Gray.

Date: September 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5951

This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile(MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLSTransport Profile is constructed. That is, these requirements indicate what management capabilities need to be available inMPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports.

RFC 5952 A Recommendation for IPv6 Address Text Representation

Authors: S. Kawamura, M. Kawashima.

Date: August 2010

Formats: txt html json

Updates: RFC 4291

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5952

As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format.

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 5954 Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261

Authors: V. Gurbani, Ed., B. Carpenter, Ed., B. Tate, Ed..

Date: August 2010

Formats: txt json html

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5954

This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261.It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses.

RFC 5955 The application/timestamped-data Media Type

Authors: A. Santoni.

Date: August 2010

Formats: txt json html

Updates: RFC 5544

Status: INFORMATIONAL

DOI: 10.17487/RFC 5955

This document defines a new media type for TimeStampedData envelopes as described in RFC 5544.

RFC 5956 Forward Error Correction Grouping Semantics in the Session Description Protocol

Authors: A. Begen.

Date: September 2010

Formats: txt html json

Obsoletes: RFC 4756

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5956

This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in theSession Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888).These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (SynchronizationSource) grouping semantics are also defined in this document forReal-time Transport Protocol (RTP) streams using SSRC multiplexing.

RFC 5957 Display-Based Address Sorting for the IMAP4 SORT Extension

Authors: D. Karp.

Date: July 2010

Formats: txt html json

Updates: RFC 5256

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5957

This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields.

RFC 5958 Asymmetric Key Packages

Authors: S. Turner.

Date: August 2010

Formats: txt json html

Obsoletes: RFC 5208

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5958

This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. TheCryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC5208.

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 5962 Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)

Authors: H. Schulzrinne, V. Singh, H. Tschofenig, M. Thomson.

Date: September 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5962

The Geopriv Location Object introduced by the Presence InformationData Format - Location Object (PIDF-LO), RFC 4119, defines a basicXML format for carrying geographical information of a presentity.This document defines PIDF-LO extensions to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity.

RFC 5963 IPv6 Deployment in Internet Exchange Points (IXPs)

Authors: R. Gagliano.

Date: August 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5963

This document provides guidance on IPv6 deployment in InternetExchange Points (IXPs). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4.

RFC 5964 Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries

Authors: J. Winterbottom, M. Thomson.

Date: August 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5964

This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a Location-to-Service Translation (LoST) server, is described.

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 5966 DNS Transport over TCP - Implementation Requirements

Authors: R. Bellis.

Date: August 2010

Formats: txt html json

Obsoleted by: RFC 7766

Updates: RFC 1035, RFC 1123

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5966

This document updates the requirements for the support of TCP as a transport protocol for DNS implementations.

RFC 5967 The application/pkcs10 Media Type

Authors: S. Turner.

Date: August 2010

Formats: txt html json

Updates: RFC 2986

Status: INFORMATIONAL

DOI: 10.17487/RFC 5967

This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986.

RFC 5968 Guidelines for Extending the RTP Control Protocol (RTCP)

Authors: J. Ott, C. Perkins.

Date: September 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5968

The RTP Control Protocol (RTCP) is used along with the Real-timeTransport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient.

RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification

Authors: W. Townsley, O. Troan.

Date: August 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5969

This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism.

RFC 5970 DHCPv6 Options for Network Boot

Authors: T. Huth, J. Freimann, V. Zimmer, D. Thaler.

Date: September 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5970

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network.

RFC 5971 GIST: General Internet Signalling Transport

Authors: H. Schulzrinne, R. Hancock.

Date: October 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5971

This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General InternetSignalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework.

RFC 5972 General Internet Signaling Transport (GIST) State Machine

Authors: T. Tsenov, H. Tschofenig, X. Fu, Ed., C. Aoun, E. Davies.

Date: October 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5972

This document describes state machines for the General InternetSignaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate howGIST may be implemented.

RFC 5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP)

Authors: M. Stiemerling, H. Tschofenig, C. Aoun, E. Davies.

Date: October 2010

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5973

This memo defines the NSIS Signaling Layer Protocol (NSLP) forNetwork Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo.

RFC 5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling

Authors: J. Manner, G. Karagiannis, A. McDonald.

Date: October 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5974

This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet.It is in accordance with the framework and requirements developed inNSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, describes the design decisions made, and provides examples. It specifies object, message formats, and processing rules.

RFC 5975 QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)

Authors: G. Ash, Ed., A. Bader, Ed., C. Kappler, Ed., D. Oran, Ed..

Date: October 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5975

The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC.This document defines a template for the QSPEC including a number ofQSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in theQSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path.

RFC 5976 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes

Authors: G. Ash, A. Morton, M. Dolly, P. Tarapore, C. Dvorak, Y. El Mghazli.

Date: October 2010

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5976

This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. Y.1541 specifies 8 classes of NetworkPerformance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines.

RFC 5977 RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv

Authors: A. Bader, L. Westberg, G. Karagiannis, C. Kappler, T. Phelan.

Date: October 2010

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5977

This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management inDiffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination.In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes.

RFC 5978 Using and Extending the NSIS Protocol Family

Authors: J. Manner, R. Bless, J. Loughney, E. Davies, Ed..

Date: October 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5978

This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010. It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs.

RFC 5979 NSIS Operation over IP Tunnels

Authors: C. Shen, H. Schulzrinne, S. Lee, J. Bang.

Date: March 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5979

NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to correspondingQoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments.

RFC 5980 NSIS Protocol Operation in Mobile Environments

Authors: T. Sanda, Ed., X. Fu, S. Jeong, J. Manner, H. Tschofenig.

Date: March 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5980

Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols.

RFC 5981 Authorization for NSIS Signaling Layer Protocols

Authors: J. Manner, M. Stiemerling, H. Tschofenig, R. Bless, Ed..

Date: February 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5981

Signaling layer protocols specified within the Next Steps inSignaling (NSIS) framework may rely on the General Internet SignalingTransport (GIST) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This document presents a generic model and object formats for session authorization within theNSIS signaling layer protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes.

RFC 5982 IP Flow Information Export (IPFIX) Mediation: Problem Statement

Authors: A. Kobayashi, Ed., B. Claise, Ed..

Date: August 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5982

Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP FlowInformation Export (IPFIX) Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIXMediation applicability examples along with the problems.

RFC 5983 Mailing Lists and Internationalized Email Addresses

Authors: R. Gellens.

Date: October 2010

Formats: txt html json

Obsoleted by: RFC 6783

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5983

This document describes considerations for mailing lists with the introduction of internationalized email addresses.
This document makes some specific recommendations on how mailing lists should act in various situations.

RFC 5984 Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding

Authors: K-M. Moller.

Date: 1 April 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 5984

This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding.

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 5986 Discovering the Local Location Information Server (LIS)

Authors: M. Thomson, J. Winterbottom.

Date: September 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5986

Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. DynamicHost Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.

RFC 5987 Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters

Authors: J. Reschke.

Date: August 2010

Formats: txt html json

Obsoleted by: RFC 8187

Status: HISTORIC

DOI: 10.17487/RFC 5987

By default, message header field parameters in Hypertext TransferProtocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC2231.

RFC 5988 Web Linking

Authors: M. Nottingham.

Date: October 2010

Formats: txt json html

Obsoleted by: RFC 8288

Updates: RFC 4287

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5988

This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field.

RFC 5989 A SIP Event Package for Subscribing to Changes to an HTTP Resource

Authors: A.B. Roach.

Date: October 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5989

The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol(HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near real- time, when a specific HTTP resource is created, changed, or deleted.This document proposes a mechanism, based on the SIP Event Framework, for doing so.

RFC 5990 Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)

Authors: J. Randall, B. Kaliski, J. Brainard, S. Turner.

Date: September 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5990

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using theRSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax(CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44.

RFC 5991 Teredo Security Updates

Authors: D. Thaler, S. Krishnan, J. Hoagland.

Date: September 2010

Formats: txt json html

Updates: RFC 4380

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5991

The Teredo protocol defines a set of flags that are embedded in everyTeredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible.

RFC 5992 Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic

Authors: S. Sharikov, D. Miloshevic, J. Klensin.

Date: October 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 5992

This document is a guideline for registries and registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Kildin Sami,Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone. It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations.

RFC 5993 RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR)

Authors: X. Duan, S. Wang, M. Westerlund, K. Hellwig, I. Johansson.

Date: October 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5993

This document specifies the payload format for packetization ofGlobal System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy.

RFC 5994 Application of Ethernet Pseudowires to MPLS Transport Networks

Authors: S. Bryant, Ed., M. Morrow, G. Swallow, R. Cherukuri, T. Nadeau, N. Harrison, B. Niven-Jenkins.

Date: October 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 5994

Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.
Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T.The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.
This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully- featured packet transport solution addressing all of the requirements of MPLS-TP.

RFC 5995 Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections

Authors: J. Reschke.

Date: September 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5995

The Hypertext Transfer Protocol (HTTP) Extensions for the WebDistributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST".
This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as theCalendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task.
This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics.

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 5997 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol

Authors: A. DeKok.

Date: August 2010

Formats: txt html json

Updates: RFC 2866

Status: INFORMATIONAL

DOI: 10.17487/RFC 5997

This document describes a deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865.

RFC 5998 An Extension for EAP-Only Authentication in IKEv2

Authors: P. Eronen, H. Tschofenig, Y. Sheffer.

Date: September 2010

Formats: txt json html

Updates: RFC 5996

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 5998

IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards.
This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures.

RFC 6001 Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)

Authors: D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, JL. Le Roux.

Date: October 2010

Formats: txt json html

Updates: RFC 4202, RFC 4203, RFC 4206, RFC 4874, RFC 4974, RFC 5307

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6001

There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).
This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer /Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain.

RFC 6002 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions

Authors: L. Berger, D. Fedyk.

Date: October 2010

Formats: txt html json

Updates: RFC 3471, RFC 3473, RFC 3945, RFC 4202, RFC 4203, RFC 5307

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6002

This document describes two technology-independent extensions toGeneralized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel SwitchingCapable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path(LSP).

RFC 6003 Ethernet Traffic Parameters

Authors: D. Papadimitriou.

Date: October 2010

Formats: txt html json

Updates: RFC 3471, RFC 3473

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6003

This document describes the support of Metro Ethernet Forum (MEF)Ethernet traffic parameters as described in MEF10.1 when usingGeneralized Multi-Protocol Label Switching (GMPLS) ResourceReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.

RFC 6004 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching

Authors: L. Berger, D. Fedyk.

Date: October 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6004

This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching(GMPLS). This document supports the types of switching corresponding to the Ethernet services that have been defined in the context of theMetro Ethernet Forum (MEF) and International Telecommunication Union(ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF- and ITU-defined parameters is also covered.

RFC 6005 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI)

Authors: L. Berger, D. Fedyk.

Date: October 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6005

This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI).This document supports the types of switching required by theEthernet services that have been defined in the context of the MetroEthernet Forum (MEF) and International Telecommunication Union (ITU)G.8011. This document is the UNI companion to "Generalized MPLS(GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet ServiceSwitching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support theUNI.

RFC 6006 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths

Authors: Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric.

Date: September 2010

Formats: txt html json

Obsoleted by: RFC 8306

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6006

Point-to-point Multiprotocol Label Switching (MPLS) and GeneralizedMPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.
This document describes extensions to the PCE communication Protocol(PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.

RFC 6007 Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations

Authors: I. Nishioka, D. King.

Date: September 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6007

A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest(PCReq) message.
This document does not specify the PCEP SVEC object or procedure.This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests.The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments.

RFC 6008 Authentication-Results Registration for Differentiating among Cryptographic Results

Authors: M. Kucherawy.

Date: September 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6008

This memo updates the registry of properties in Authentication-Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent.

RFC 6009 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions

Authors: N. Freed.

Date: October 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6009

This document describes the "envelope-dsn", "redirect-dsn","envelope-deliverby", and "redirect-deliverby" extensions to theSieve email filtering language. The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification (DSN) andDeliver-By SMTP extensions, respectively. The "redirect-dsn" and"redirect-deliverby" extensions extend Sieve's redirect action to provide control over delivery status notification and Deliver-By parameters, respectively.

RFC 6010 Cryptographic Message Syntax (CMS) Content Constraints Extension

Authors: R. Housley, S. Ashmore, C. Wallace.

Date: September 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6010

This document specifies the syntax and semantics for theCryptographic Message Syntax (CMS) content constraints extension.This extension is used to determine whether a public key is appropriate to use in the processing of a protected content. In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMSAuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate. If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes.

RFC 6011 Session Initiation Protocol (SIP) User Agent Configuration

Authors: S. Lawrence, Ed., J. Elwell.

Date: October 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6011

This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service.

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 6013 TCP Cookie Transactions (TCPCT)

Authors: W. Simpson.

Date: January 2011

Formats: txt html json

Obsoleted by: RFC 7805

Status: HISTORIC

DOI: 10.17487/RFC 6013

TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks.

RFC 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 6015 RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)

Authors: A. Begen.

Date: October 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6015

This document defines a new RTP payload format for the Forward ErrorCorrection (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity. The new payload format defined in this document should only be used (with some exceptions) as a part of the Digital Video Broadcasting-IPTV (DVB-IPTV) Application-layer FEC specification.

RFC 6016 Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs

Authors: B. Davie, F. Le Faucheur, A. Narayanan.

Date: October 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6016

RFC 4364 and RFC 4659 define an approach to building provider- provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers andProvider Edge (PE) routers. This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported.

RFC 6017 Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field

Authors: K. Meadors, Ed..

Date: September 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6017

With the maturity of the Electronic Data Interchange - InternetIntegration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by allEDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality.

RFC 6018 IPv4 and IPv6 Greynets

Authors: F. Baker, W. Harrop, G. Armitage.

Date: September 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6018

This note discusses a feature to support building Greynets for IPv4 and IPv6.

RFC 6019 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1

Authors: R. Housley.

Date: September 2010

Formats: txt json html

Obsoletes: RFC 4049

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6019

This document specifies a new ASN.1 type for representing time:BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary- signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652.

RFC 6020 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)

Authors: M. Bjorklund, Ed..

Date: October 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6020

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol(NETCONF), NETCONF remote procedure calls, and NETCONF notifications.

RFC 6021 Common YANG Data Types

Authors: J. Schoenwaelder, Ed..

Date: October 2010

Formats: txt json html

Obsoleted by: RFC 6991

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6021

This document introduces a collection of common data types to be used with the YANG data modeling language.

RFC 6022 YANG Module for NETCONF Monitoring

Authors: M. Scott, M. Bjorklund.

Date: October 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6022

This document defines a Network Configuration Protocol (NETCONF) data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics. This data facilitates the management of aNETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF <get-schema&rt; operation to retrieve them.

RFC 6023 A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)

Authors: Y. Nir, H. Tschofenig, H. Deng, R. Singh.

Date: October 2010

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6023

This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association(SA) to be created and authenticated without generating a Child SA.

RFC 6024 Trust Anchor Management Requirements

Authors: R. Reddy, C. Wallace.

Date: October 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6024

A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems.

RFC 6025 ASN.1 Translation

Authors: C. Wallace, C. Gardiner.

Date: October 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6025

Abstract Syntax Notation One (ASN.1) is widely used throughout theIETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1.Instead, it addresses ASN.1 features that are used in IETF SecurityArea specifications with a focus on items that vary with the ASN.1 version.

RFC 6026 Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests

Authors: R. Sparks, T. Zourzouvillys.

Date: September 2010

Formats: txt html json

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6026

This document normatively updates RFC 3261, the Session InitiationProtocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements followingRFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request. The correction involves modifying theINVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk.

RFC 6027 IPsec Cluster Problem Statement

Authors: Y. Nir.

Date: October 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6027

This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations.

RFC 6028 Host Identity Protocol (HIP) Multi-Hop Routing Extension

Authors: G. Camarillo, A. Keranen.

Date: October 2010

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6028

This document specifies two extensions to the Host Identity Protocol(HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse.The second extension allows a HIP packet to carry and record the list of nodes that forwarded it.

RFC 6029 A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem

Authors: I. Rimac, V. Hilt, M. Tomsu, V. Gurbani, E. Marocco.

Date: October 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6029

A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming.Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization.

RFC 6030 Portable Symmetric Key Container (PSKC)

Authors: P. Hoyer, M. Pei, S. Machani.

Date: October 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6030

This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules.For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure.

RFC 6031 Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type

Authors: S. Turner, R. Housley.

Date: December 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6031

This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type.

RFC 6032 Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type

Authors: S. Turner, R. Housley.

Date: December 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6032

This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS ContentConstraints (CCC) extension, which does not constrain theEncryptedData, EnvelopedData, and AuthEnvelopedData.

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 6034 Unicast-Prefix-Based IPv4 Multicast Addresses

Authors: D. Thaler.

Date: October 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6034

This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment 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 6035 Session Initiation Protocol Event Package for Voice Quality Reporting

Authors: A. Pendleton, A. Clark, A. Johnston, H. Sinnreich.

Date: November 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6035

This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions.Voice call quality information derived from RTP Control ProtocolExtended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector. A registration for the application/ vq- rtcpxr media type is also included.

RFC 6036 Emerging Service Provider Scenarios for IPv6 Deployment

Authors: B. Carpenter, S. Jiang.

Date: October 2010

Formats: txt html json

Obsoleted by: RFC 9386

Status: INFORMATIONAL

DOI: 10.17487/RFC 6036

This document describes practices and plans that are emerging amongInternet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations.

RFC 6037 Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs

Authors: E. Rosen, Ed., Y. Cai, Ed., IJ. Wijnands.

Date: October 2010

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 6037

This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalizedMVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document.

RFC 6038 Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features

Authors: A. Morton, L. Ciavattone.

Date: October 2010

Formats: txt json html

Updates: RFC 5357

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6038

This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions.

RFC 6039 Issues with Existing Cryptographic Protection Methods for Routing Protocols

Authors: V. Manral, M. Bhatia, J. Jaeggli, R. White.

Date: October 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6039

Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.
The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.
This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations.

RFC 6040 Tunnelling of Explicit Congestion Notification

Authors: B. Briscoe.

Date: November 2010

Formats: txt html json

Updates: RFC 3168, RFC 4301, RFC 4774

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6040

This document redefines how the explicit congestion notification(ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301IPsec ECN processing. On decapsulation, it updates both RFC 3168 andRFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification --PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues.

RFC 6041 Forwarding and Control Element Separation (ForCES) Applicability Statement

Authors: A. Crouch, H. Khosravi, A. Doria, Ed., X. Wang, K. Ogawa.

Date: October 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6041

The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES.

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 6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)

Authors: M. Mohali.

Date: October 2010

Formats: txt html json

Obsoleted by: RFC 7544

Status: INFORMATIONAL

DOI: 10.17487/RFC 6044

Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.
This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.
Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment.

RFC 6045 Real-time Inter-network Defense (RID)

Authors: K. Moriarty.

Date: November 2010

Formats: txt html json

Obsoleted by: RFC 6545

Status: INFORMATIONAL

DOI: 10.17487/RFC 6045

Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system.Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.
RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter- network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here.

RFC 6046 Transport of Real-time Inter-network Defense (RID) Messages

Authors: K. Moriarty, B. Trammell.

Date: November 2010

Formats: txt json html

Obsoleted by: RFC 6546

Status: INFORMATIONAL

DOI: 10.17487/RFC 6046

The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-networkDefense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security).

RFC 6047 iCalendar Message-Based Interoperability Protocol (iMIP)

Authors: A. Melnikov, Ed..

Date: December 2010

Formats: txt json html

Obsoletes: RFC 2447

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6047

This document, "iCalendar Message-Based Interoperability Protocol(iMIP)", specifies a binding from the iCalendar Transport-independentInteroperability Protocol (iTIP) to Internet email-based transports.Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC2046, RFC 2047, and RFC 2049), and then transported over SMTP.

RFC 6048 Network News Transfer Protocol (NNTP) Additions to LIST Command

Authors: J. Elie.

Date: November 2010

Formats: txt html json

Updates: RFC 2980, RFC 3977

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6048

This document defines a set of enhancements to the Network NewsTransfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977.
This memo updates and formalizes the LIST DISTRIBUTIONS and LISTSUBSCRIPTIONS commands defined in RFC 2980. It also adds the LISTCOUNTS, LIST MODERATORS, and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup.

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 6050 A Session Initiation Protocol (SIP) Extension for the Identification of Services

Authors: K. Drage.

Date: November 2010

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6050

This document describes private extensions to the Session InitiationProtocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. 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 service identification model suitable for use between different trust domains or for use in the Internet at large.
The document also defines a URN to identify both services and UserAgent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs.

RFC 6051 Rapid Synchronisation of RTP Flows

Authors: C. Perkins, T. Schierl.

Date: November 2010

Formats: txt html json

Updates: RFC 3550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6051

This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.
This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol(RTCP) timing rules to reduce the initial synchronisation delay forSSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew.

RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators

Authors: C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li.

Date: October 2010

Formats: txt json html

Updates: RFC 4291

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6052

This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios.

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 6054 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic

Authors: D. McGrew, B. Weis.

Date: November 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6054

Counter modes have been defined for block ciphers such as theAdvanced Encryption Standard (AES). Counter modes use a counter, which is typically assumed to be incremented by a single sender.This memo describes the use of counter modes when applied to theEncapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications.

RFC 6055 IAB Thoughts on Encodings for Internationalized Domain Names

Authors: D. Thaler, J. Klensin, S. Cheshire.

Date: February 2011

Formats: txt html json

Updates: RFC 2130

Status: INFORMATIONAL

DOI: 10.17487/RFC 6055

This document explores issues with Internationalized Domain Names(IDNs) that result from the use of various encoding schemes such asUTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.

RFC 6056 Recommendations for Transport-Protocol Port Randomization

Authors: M. Larsen, F. Gont.

Date: January 2011

Formats: txt json html

Also: BCP 0156

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6056

During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the TransmissionControl Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, DestinationAddress, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such asTCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP),Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers).

RFC 6057 Comcast's Protocol-Agnostic Congestion Management System

Authors: C. Bastian, T. Klieber, J. Livingood, J. Mills, R. Woundy.

Date: December 2010

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 6057

This document describes the congestion management system of ComcastCable, a large cable broadband Internet Service Provider (ISP) in theU.S. Comcast completed deployment of this congestion management system on December 31, 2008.

RFC 6058 Transient Binding for Proxy Mobile IPv6

Authors: M. Liebsch, Ed., A. Muhanna, O. Blume.

Date: March 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6058

This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the ProxyMobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss.

RFC 6059 Simple Procedures for Detecting Network Attachment in IPv6

Authors: S. Krishnan, G. Daley.

Date: November 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6059

Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for DetectingNetwork Attachment in IPv6 hosts, and procedures for routers to support such services.

RFC 6060 Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)

Authors: D. Fedyk, H. Shah, N. Bitar, A. Takacs.

Date: March 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6060

This specification is complementary to the GMPLS Ethernet LabelSwitching Architecture and Framework and describes the technology- specific aspects of GMPLS control for Provider Backbone BridgeTraffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point(P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane.

RFC 6061 Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA)

Authors: B. Rosen.

Date: January 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6061

This document describes the Namespace Identifier (NID) "nena" forUniform Resource Name (URN) resources published by the NationalEmergency Number Association (NENA). NENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the NENA RegistrySystem (NRS).

RFC 6062 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations

Authors: S. Perreault, Ed., J. Rosenberg.

Date: November 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6062

This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator(NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers.TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from theTURN server.

RFC 6063 Dynamic Symmetric Key Provisioning Protocol (DSKPP)

Authors: A. Doherty, M. Pei, S. Machani, M. Nystrom.

Date: December 2010

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6063

The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client- server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.
Two variations of the protocol support multiple usage scenarios.With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre- generated symmetric keys to a cryptographic module.

RFC 6064 SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service

Authors: M. Westerlund, P. Frojdh.

Date: January 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6064

The Packet-switched Streaming Service (PSS) and the MultimediaBroadcast/Multicast Service (MBMS) defined by 3GPP use the SessionDescription Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA.

RFC 6065 Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings

Authors: K. Narayan, D. Nelson, R. Presuhn, Ed..

Date: December 2010

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6065

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting(AAA) services, such as the Remote Authentication Dial-In UserService (RADIUS), to dynamically update user-to-group mappings in theView-based Access Control Model (VACM).

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 6067 BCP 47 Extension U

Authors: M. Davis, A. Phillips, Y. Umaoka.

Date: December 2010

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6067

This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium.

RFC 6068 The 'mailto' URI Scheme

Authors: M. Duerst, L. Masinter, J. Zawinski.

Date: October 2010

Formats: txt html json

Obsoletes: RFC 2368

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6068

This document defines the format of Uniform Resource Identifiers(URIs) to identify resources that are reached using Internet mail.It adds better internationalization and compatibility withInternationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368).

RFC 6069 Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD)

Authors: A. Zimmermann, A. Hannemann.

Date: December 2010

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6069

Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs.This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.
This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions.

RFC 6070 PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors

Authors: S. Josefsson.

Date: January 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6070

This document contains test vectors for the Public-Key CryptographyStandards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure HashAlgorithm (SHA-1) pseudorandom function.

RFC 6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap

Authors: S. Frankel, S. Krishnan.

Date: February 2011

Formats: txt html json

Obsoletes: RFC 2411

Status: INFORMATIONAL

DOI: 10.17487/RFC 6071

Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.
This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IPSecurity Document Roadmap."
The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents.The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms.

RFC 6072 Certificate Management Service for the Session Initiation Protocol (SIP)

Authors: C. Jennings, J. Fischl, Ed..

Date: February 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6072

This document defines a credential service that allows SessionInitiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows User Agents that want to contact a given Address-of-Record(AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate. The credential service also allows users to store and retrieve their own certificates and private keys.

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 6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)

Authors: E. Rosen, B. Davie, V. Radoaca, W. Luo.

Date: January 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6074

Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a"discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN.This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3).

RFC 6075 The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry

Authors: D. Cridland.

Date: December 2010

Formats: txt html json

Updates: RFC 2244

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6075

The original Application Configuration Access Protocol (ACAP) specification included a vendor registry now used in other protocols.This document updates the description of this registry, removing the need for a direct normative reference to ACAP and removing ambiguity.

RFC 6076 Basic Telephony SIP End-to-End Performance Metrics

Authors: D. Malas, A. Morton.

Date: January 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6076

This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations.

RFC 6077 Open Research Issues in Internet Congestion Control

Authors: D. Papadimitriou, Ed., M. Welzl, M. Scharf, B. Briscoe.

Date: February 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6077

This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet- scale solutions can be confidently engineered and deployed.

RFC 6078 Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)

Authors: G. Camarillo, J. Melen.

Date: January 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6078

This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks.

RFC 6079 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)

Authors: G. Camarillo, P. Nikander, J. Hautakorpi, A. Keranen, A. Johnston.

Date: January 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6079

This document specifies a framework to build HIP-based (Host IdentityProtocol) overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as "peer protocols".

RFC 6080 A Framework for Session Initiation Protocol User Agent Profile Delivery

Authors: D. Petrie, S. Channabasappa, Ed..

Date: March 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6080

This document specifies a framework to enable configuration ofSession Initiation Protocol (SIP) user agents (UAs) in SIP deployments. The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope.

RFC 6081 Teredo Extensions

Authors: D. Thaler.

Date: January 2011

Formats: txt html json

Updates: RFC 4380

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6081

This document specifies a set of extensions to the Teredo protocol.These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication.

RFC 6082 Deprecating Unicode Language Tag Characters: RFC 2482 is Historic

Authors: K. Whistler, G. Adams, M. Duerst, R. Presuhn, Ed., J. Klensin.

Date: November 2010

Formats: txt json html

Obsoletes: RFC 2482

Status: INFORMATIONAL

DOI: 10.17487/RFC 6082

RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML. The Unicode Consortium has deprecated that facility and strongly recommends against its use. RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages.

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 6085 Address Mapping of IPv6 Multicast Packets on Ethernet

Authors: S. Gundavelli, M. Townsley, O. Troan, W. Dec.

Date: January 2011

Formats: txt html json

Updates: RFC 2464

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6085

When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link- layer multicast address. This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address.

RFC 6086 Session Initiation Protocol (SIP) INFO Method and Package Framework

Authors: C. Holmberg, E. Burger, H. Kaplan.

Date: January 2011

Formats: txt json html

Obsoletes: RFC 2976

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6086

This document defines a method, INFO, for the Session InitiationProtocol (SIP), and an Info Package mechanism. This document obsoletes RFC 2976. For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document.

RFC 6087 Guidelines for Authors and Reviewers of YANG Data Model Documents

Authors: A. Bierman.

Date: January 2011

Formats: txt json html

Obsoleted by: RFC 8407

Status: INFORMATIONAL

DOI: 10.17487/RFC 6087

This memo provides guidelines for authors and reviewers of StandardsTrack specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NetworkConfiguration Protocol (NETCONF) implementations that utilize YANG data model modules.

RFC 6088 Traffic Selectors for Flow Bindings

Authors: G. Tsirtsis, G. Giarreta, H. Soliman, N. Montavont.

Date: January 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6088

This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for MobileIPv6.

RFC 6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support

Authors: G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, K. Kuladinithi.

Date: January 2011

Formats: txt html json

Updates: RFC 5648

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6089

This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses.

RFC 6090 Fundamental Elliptic Curve Cryptography Algorithms

Authors: D. McGrew, K. Igoe, M. Salter.

Date: February 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6090

This note describes the fundamental algorithms of Elliptic CurveCryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B.

RFC 6091 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication

Authors: N. Mavrogiannopoulos, D. Gillmor.

Date: February 2011

Formats: txt html json

Obsoletes: RFC 5081

Status: INFORMATIONAL

DOI: 10.17487/RFC 6091

This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types.

RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service

Authors: J. Woodyatt, Ed..

Date: January 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6092

This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks inInternet-enabled homes and small offices.

RFC 6093 On the Implementation of the TCP Urgent Mechanism

Authors: F. Gont, A. Yourtchenko.

Date: January 2011

Formats: txt json html

Obsoleted by: RFC 9293

Updates: RFC 0793, RFC 1011, RFC 1122

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6093

This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications(but provides advice to applications that do).

RFC 6094 Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols

Authors: M. Bhatia, V. Manral.

Date: February 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6094

The routing protocols Open Shortest Path First version 2 (OSPFv2),Intermediate System to Intermediate System (IS-IS), and RoutingInformation Protocol (RIP) currently define cleartext and MD5(Message Digest 5) methods for authenticating protocol packets.Recently, effort has been made to add support for the SHA (SecureHash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF.
To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common.
Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets.
This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time.

RFC 6095 Extending YANG with Language Abstractions

Authors: B. Linowski, M. Ersue, S. Kuryla.

Date: March 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6095

YANG -- the Network Configuration Protocol (NETCONF) Data ModelingLanguage -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancingYANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse.

RFC 6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration

Authors: M. Tuexen, R. Stewart.

Date: January 2011

Formats: txt json html

Obsoleted by: RFC 9260

Updates: RFC 4960

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6096

This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream ControlTransmission Protocol (SCTP). It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way.

RFC 6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6

Authors: J. Korhonen, V. Devarapalli.

Date: February 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6097

Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to aProxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in theMobile Access Gateway. This document describes several possible dynamic Local Mobility Anchor discovery solutions.

RFC 6098 Generic Notification Message for Mobile IPv4

Authors: H. Deng, H. Levkowetz, V. Devarapalli, S. Gundavelli, B. Haley.

Date: April 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6098

This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using aMobile IPv4 message type designed for this purpose.

RFC 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0

Authors: A. Freier, P. Karlton, P. Kocher.

Date: August 2011

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 6101

This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.
This document specifies version 3.0 of the Secure Sockets Layer (SSL3.0) protocol, a security protocol that 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 6104 Rogue IPv6 Router Advertisement Problem Statement

Authors: T. Chown, S. Venaas.

Date: February 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6104

When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed.

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 6106 IPv6 Router Advertisement Options for DNS Configuration

Authors: J. Jeong, S. Park, L. Beloeil, S. Madanapalli.

Date: November 2010

Formats: txt json html

Obsoletes: RFC 5006

Obsoleted by: RFC 8106

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6106

This document specifies IPv6 Router Advertisement options to allowIPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts.

RFC 6107 Procedures for Dynamically Signaled Hierarchical Label Switched Paths

Authors: K. Shiomoto, Ed., A. Farrel, Ed..

Date: February 2011

Formats: txt json html

Updates: RFC 3477, RFC 4206

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6107

Label Switched Paths (LSPs) set up in Multiprotocol Label Switching(MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.
Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process.
The mechanisms defined in this document deprecate the technique for the signaling of LSPs that are to be used as numbered TE links described in RFC 4206.

RFC 6108 Comcast's Web Notification System Design

Authors: C. Chung, A. Kasyanov, J. Livingood, N. Mody, B. Van Lieu.

Date: February 2011

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 6108

The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection.There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications.

RFC 6109 La Posta Elettronica Certificata - Italian Certified Electronic Mail

Authors: C. Petrucci, F. Gennai, A. Shahin, A. Vinciarelli.

Date: April 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6109

Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "PostaElettronica Certificata") were defined, giving the system legal standing.
The design of the entire system was carried out by the NationalCenter for Informatics in the Public Administration of Italy(DigitPA), followed by efforts for the implementation and testing of the service. The DigitPA has given the Italian National ResearchCouncil (CNR), and in particular the Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005.

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 6111 Additional Kerberos Naming Constraints

Authors: L. Zhu.

Date: April 2011

Formats: txt html json

Updates: RFC 4120

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6111

This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names.

RFC 6112 Anonymity Support for Kerberos

Authors: L. Zhu, P. Leach, S. Hartman.

Date: April 2011

Formats: txt json html

Obsoleted by: RFC 8062

Updates: RFC 4120, RFC 4121, RFC 4556

Status: HISTORIC

DOI: 10.17487/RFC 6112

This document defines extensions to the Kerberos protocol to allow aKerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow aKerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556.

RFC 6113 A Generalized Framework for Kerberos Pre-Authentication

Authors: S. Hartman, L. Zhu.

Date: April 2011

Formats: txt json html

Updates: RFC 4120

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6113

Kerberos is a protocol for verifying the identity of principals(e.g., a workstation user or a network server) on an open network.The Kerberos protocol provides a facility called pre-authentication.Pre-authentication mechanisms can use this facility to extend theKerberos protocol and prove the identity of a principal.
This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre- authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact.
This document also provides common tools needed by multiple pre- authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm.

RFC 6114 The 128-Bit Blockcipher CLEFIA

Authors: M. Katagi, S. Moriai.

Date: March 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6114

This document describes the specification of the blockcipher CLEFIA.CLEFIA is a 128-bit blockcipher, with key lengths of 128, 192, and256 bits, which is compatible with the interface of the AdvancedEncryption Standard (AES). The algorithm of CLEFIA was published in2007, and its security has been scrutinized in the public community.CLEFIA is one of the new-generation lightweight blockcipher algorithms designed after AES. Among them, CLEFIA offers high performance in software and hardware as well as lightweight implementation in hardware. CLEFIA will be of benefit to theInternet, which will be connected to more distributed and constrained devices.

RFC 6115 Recommendation for a Routing Architecture

Authors: T. Li, Ed..

Date: February 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6115

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group.

RFC 6116 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)

Authors: S. Bradner, L. Conroy, K. Fujiwara.

Date: March 2011

Formats: txt json html

Obsoletes: RFC 3761

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6116

This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761.

RFC 6117 IANA Registration of Enumservices: Guide, Template, and IANA Considerations

Authors: B. Hoeneisen, A. Mayrhofer, J. Livingood.

Date: March 2011

Formats: txt json html

Obsoletes: RFC 3761

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6117

This document specifies a revision of the IANA RegistrationGuidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating EnumserviceSpecifications.

RFC 6118 Update of Legacy IANA Registrations of Enumservices

Authors: B. Hoeneisen, A. Mayrhofer.

Date: March 2011

Formats: txt html json

Updates: RFC 3762, RFC 3764, RFC 3953, RFC 4143, RFC 4002, RFC 4238, RFC 4355, RFC 4415, RFC 4769, RFC 4969, RFC 4979, RFC 5028, RFC 5278, RFC 5333

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6118

This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761.

RFC 6119 IPv6 Traffic Engineering in IS-IS

Authors: J. Harrison, J. Berger, M. Bartlett.

Date: February 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6119

This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic- engineered routes using IPv6 addresses.

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 6121 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence

Authors: P. Saint-Andre.

Date: March 2011

Formats: txt html json

Obsoletes: RFC 3921

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6121

This document defines extensions to core features of the ExtensibleMessaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921.

RFC 6122 Extensible Messaging and Presence Protocol (XMPP): Address Format

Authors: P. Saint-Andre.

Date: March 2011

Formats: txt json html

Obsoleted by: RFC 7622

Updates: RFC 3920

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6122

This document defines the format for addresses used in the ExtensibleMessaging and Presence Protocol (XMPP), including support for non-ASCII characters. This document updates RFC 3920.

RFC 6123 Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts

Authors: A. Farrel.

Date: February 2011

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 6123

It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal.Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.
The Operations Area has developed "Guidelines for ConsideringOperations and Management of New Protocols and Protocol Extensions"(RFC 5706), and those guidelines have been adopted by the PathComputation Element (PCE) Working Group.
Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference.

RFC 6124 An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol

Authors: Y. Sheffer, G. Zorn, H. Tschofenig, S. Fluhrer.

Date: February 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6124

The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates.

RFC 6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)

Authors: P. Saint-Andre, J. Hodges.

Date: March 2011

Formats: txt html json

Obsoleted by: RFC 9525

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6125

Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509(PKIX) certificates in the context of Transport Layer Security (TLS).This document specifies procedures for representing and verifying the identity of application services in such interactions.

RFC 6126 The Babel Routing Protocol

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 6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios

Authors: J. Arkko, M. Townsley.

Date: May 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6127

When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.
This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on newIPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition.

RFC 6128 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions

Authors: A. Begen.

Date: February 2011

Formats: txt html json

Updates: RFC 5760

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6128

The Session Description Protocol (SDP) has an attribute that allowsRTP applications to specify an address and a port associated with theRTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute.

RFC 6129 The 'application/tei+xml' Media Type

Authors: L. Romary, S. Lundberg.

Date: February 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6129

This document defines the 'application/tei+xml' media type for markup languages defined in accordance with the Text Encoding andInterchange guidelines.

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 6131 Sieve Vacation Extension: "Seconds" Parameter

Authors: R. George, B. Leiba.

Date: July 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6131

This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ":seconds" parameter.

RFC 6132 Sieve Notification Using Presence Information

Authors: R. George, B. Leiba.

Date: July 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6132

This is a further extension to the Sieve mail filtering languageNotification extension, defining presence information that may be checked through the notify_method_capability feature.

RFC 6133 Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality

Authors: R. George, B. Leiba, A. Melnikov.

Date: July 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6133

This document describes how the Sieve email filtering language, along with some extensions, can be used to create automatic replies to incoming electronic mail messages based on the address book and presence information of the recipient.

RFC 6134 Sieve Extension: Externally Stored Lists

Authors: A. Melnikov, B. Leiba.

Date: July 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6134

The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server.
This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol(LDAP), the Application Configuration Access Protocol (ACAP), vCardExtensions to WebDAV (CardDAV), or relational databases.

RFC 6135 An Alternative Connection Model for the Message Session Relay Protocol (MSRP)

Authors: C. Holmberg, S. Blau.

Date: February 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6135

This document defines an alternative connection model for MessageSession Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create theMSRP transport connection. The model allows MSRP UAs behind NetworkAddress Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT.

RFC 6136 Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework

Authors: A. Sajassi, Ed., D. Mohan, Ed..

Date: March 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6136

This document provides framework and requirements for Layer 2 VirtualPrivate Network (L2VPN) Operations, Administration, and Maintenance(OAM). The OAM framework is intended to provide OAM layering acrossL2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is intended to identify OAM requirements forL2VPN services, i.e., Virtual Private LAN Service (VPLS), VirtualPrivate Wire Service (VPWS), and IP-only LAN Service (IPLS).Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSNOAM requirements are also identified.

RFC 6137 The Network Trouble Ticket Data Model (NTTDM)

Authors: D. Zisiadis, Ed., S. Kopsidas, Ed., M. Tsavli, Ed., G. Cessieux, Ed..

Date: February 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6137

Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. A Grid is a good example of such a multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. TheTT systems of the participants collect, represent, and disseminate TT information in different formats.
As a result, management of the daily workload by a central NetworkOperation Centre (NOC) is a challenge on its own. Normalization ofTTs to a common format at the central NOC can ease presentation, storing, and handling of the TTs. In the present document, we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE(Enabling Grids for E-sciencE) project.

RFC 6138 LDP IGP Synchronization for Broadcast Networks

Authors: S. Kini, Ed., W. Lu, Ed..

Date: February 2011

Formats: txt html json

Updates: RFC 5443

Status: INFORMATIONAL

DOI: 10.17487/RFC 6138

RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior GatewayProtocol (IGP) is operational on a link but Label DistributionProtocol (LDP) is not. If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use- case without dropping traffic. The mechanism does not introduce any protocol message changes.

RFC 6139 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios

Authors: S. Russert, Ed., E. Fleischman, Ed., F. Templin, Ed..

Date: February 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6139

"Routing and Addressing in Networks with Global Enterprise Recursion(RANGER)" (RFC 5720) provides an architectural framework for scalable routing and addressing. It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security. This document describes a series of use cases in order to showcase the architectural capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet.

RFC 6140 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)

Authors: A.B. Roach.

Date: March 2011

Formats: txt json html

Updates: RFC 3680

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6140

This document defines a mechanism by which a Session InitiationProtocol (SIP) server acting as a traditional Private Branch Exchange(PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs). In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts. This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique.This document therefore focuses on this use case.

RFC 6141 Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)

Authors: G. Camarillo, Ed., C. Holmberg, Y. Gao.

Date: March 2011

Formats: txt json html

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6141

The procedures for handling SIP re-INVITEs are described in RFC 3261.Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests.

RFC 6142 ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP

Authors: A. Moise, J. Brodkin.

Date: March 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6142

This RFC provides a framework for transporting ANSI C12.22/IEEE1703/MC12.22 Advanced Metering Infrastructure (AMI) Application LayerMessages on an IP network.
This document is not an official submission on behalf of the ANSIC12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations.

RFC 6143 The Remote Framebuffer Protocol

Authors: T. Richardson, J. Levine.

Date: March 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6143

RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces that allows a client to view and control a window system on another computer. Because it works at the framebuffer level, RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC.

RFC 6144 Framework for IPv4/IPv6 Translation

Authors: F. Baker, X. Li, C. Bao, K. Yin.

Date: April 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6144

This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - ProtocolTranslation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network.

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 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers

Authors: M. Bagnulo, P. Matthews, I. van Beijnum.

Date: April 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6146

This document describes stateful NAT64 translation, which allowsIPv6-only clients to contact IPv4 servers using unicast UDP, TCP, orICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When statefulNAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server.

RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers

Authors: M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum.

Date: April 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6147

DNS64 is a mechanism for synthesizing AAAA records from A records.DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators.

RFC 6148 DHCPv4 Lease Query by Relay Agent Remote ID

Authors: P. Kurapati, R. Desetti, B. Joshi.

Date: February 2011

Formats: txt json html

Updates: RFC 4388

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6148

Some relay agents extract lease information from the DHCP messages exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing and prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server when this information is lost. The existing lease query mechanism is data-driven, which means that a relay agent can initiate the lease query only when it starts receiving data to and from the clients. In certain scenarios, this model is not scalable. This document first looks at issues in the existing mechanism and then proposes a new query type, query by Remote ID, to address these issues.

RFC 6149 MD2 to Historic Status

Authors: S. Turner, L. Chen.

Date: March 2011

Formats: txt json html

Obsoletes: RFC 1319

Status: INFORMATIONAL

DOI: 10.17487/RFC 6149

This document retires MD2 and discusses the reasons for doing so.This document moves RFC 1319 to Historic status.

RFC 6150 MD4 to Historic Status

Authors: S. Turner, L. Chen.

Date: March 2011

Formats: txt json html

Obsoletes: RFC 1320

Status: INFORMATIONAL

DOI: 10.17487/RFC 6150

This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so. This document moves RFC 1320 to Historic status.

RFC 6151 Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms

Authors: S. Turner, L. Chen.

Date: March 2011

Formats: txt json html

Updates: RFC 1321, RFC 2104

Status: INFORMATIONAL

DOI: 10.17487/RFC 6151

This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations forHMAC-MD5.

RFC 6152 SMTP Service Extension for 8-bit MIME Transport

Authors: J. Klensin, N. Freed, M. Rose, D. Crocker, Ed..

Date: March 2011

Formats: txt html json

Obsoletes: RFC 1652

Also: STD 0071

Status: INTERNET STANDARD

DOI: 10.17487/RFC 6152

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of theUS-ASCII octet range (hex 00-7F) may be relayed using SMTP.

RFC 6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery

Authors: S. Das, G. Bajko.

Date: February 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6153

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover AccessNetwork Discovery and Selection Function (ANDSF) entities in an IP network. ANDSF is being developed in the Third GenerationPartnership Project (3GPP) and provides inter-system mobility policies and access-network-specific information to the mobile nodes(MNs).

RFC 6154 IMAP LIST Extension for Special-Use Mailboxes

Authors: B. Leiba, J. Nicolson.

Date: March 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6154

Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration.

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 6156 Traversal Using Relays around NAT (TURN) Extension for IPv6

Authors: G. Camarillo, O. Novo, S. Perreault, Ed..

Date: April 2011

Formats: txt html json

Obsoleted by: RFC 8656

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6156

This document adds IPv6 support to Traversal Using Relays around NAT(TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED-ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type theTURN server will allocate (e.g., an IPv4-only node may request theTURN server to allocate an IPv6 address).

RFC 6157 IPv6 Transition in the Session Initiation Protocol (SIP)

Authors: G. Camarillo, K. El Malki, V. Gurbani.

Date: April 2011

Formats: txt html json

Updates: RFC 3264

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6157

This document describes how the IPv4 Session Initiation Protocol(SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack(i.e., IPv4-only and IPv4/IPv6) user agents are considered.

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 6159 Session-Specific Explicit Diameter Request Routing

Authors: T. Tsou, G. Zorn, T. Taylor, Ed..

Date: April 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6159

This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting aDiameter session.

RFC 6160 Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types

Authors: S. Turner.

Date: April 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6160

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type. Specifically, it includes conventions necessary to implement SignedData,EnvelopedData, EncryptedData, and AuthEnvelopedData.

RFC 6161 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type

Authors: S. Turner.

Date: April 2011

Formats: txt json html

Updates: RFC 6033

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6161

This document describes the conventions for using several EllipticCurve cryptographic algorithms with the Cryptographic Message Syntax(CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman(ECDH) with EnvelopedData and Elliptic Curve Digital SignatureAlgorithm (ECDSA) with SignedData. This document extends RFC 6033.

RFC 6162 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type

Authors: S. Turner.

Date: April 2011

Formats: txt html json

Updates: RFC 5959

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6162

This document describes conventions for using Elliptic Curve cryptographic algorithms with SignedData and EnvelopedData to protect the AsymmetricKeyPackage content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman(ECDH) with EnvelopedData and Elliptic Curve Digital SignatureAlgorithm (ECDSA) with SignedData. This document extends RFC 5959.

RFC 6163 Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)

Authors: Y. Lee, Ed., G. Bernstein, Ed., W. Imajuku.

Date: April 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6163

This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element(PCE) architecture to the control of Wavelength Switched OpticalNetworks (WSONs). In particular, it examines Routing and WavelengthAssignment (RWA) of optical paths.
This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth.

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 6165 Extensions to IS-IS for Layer-2 Systems

Authors: A. Banerjee, D. Ward.

Date: April 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6165

This document specifies the Intermediate System to IntermediateSystem (IS-IS) extensions necessary to support link state routing for any protocols running directly over Layer-2. While supporting this concept involves several pieces, this document only describes extensions to IS-IS. Furthermore, the Type, Length, Value pairs(TLVs) described in this document are generic Layer-2 additions, and specific ones as needed are defined in the IS-IS technology-specific extensions. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used.

RFC 6166 A Registry for PIM Message Types

Authors: S. Venaas.

Date: April 2011

Formats: txt html json

Obsoleted by: RFC 8736

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6166

This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types.It also specifies a procedure for registering new types.
In addition to this, one message type is reserved, and may be used for a future extension of the message type space.

RFC 6167 URI Scheme for Java(tm) Message Service 1.0

Authors: M. Phillips, P. Adams, D. Rokicki, E. Johnson.

Date: April 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6167

This document defines the format of Uniform Resource Identifiers(URIs) as defined in RFC 3986, for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS).It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS Destination. The syntax of this JMSURI is not compatible with previously existing, but unregistered,"jms" URI schemes. However, the expressiveness of the scheme described herein should satisfy the requirements of all existing circumstances.

RFC 6168 Requirements for Management of Name Servers for the DNS

Authors: W. Hardaker.

Date: May 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6168

Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.
This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system.

RFC 6169 Security Concerns with IP Tunneling

Authors: S. Krishnan, D. Thaler, J. Hoagland.

Date: April 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6169

A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues.

RFC 6170 Internet X.509 Public Key Infrastructure -- Certificate Image

Authors: S. Santesson, R. Housley, S. Bajaj, L. Rosenthol.

Date: May 2011

Formats: txt json html

Obsoleted by: RFC 9399

Updates: RFC 3709

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6170

This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709.

RFC 6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control

Authors: K. Zeilenga.

Date: March 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6171

This document defines the Lightweight Directory Access Protocol(LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option.

RFC 6172 Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode

Authors: D. Black, D. Peterson.

Date: March 2011

Formats: txt html json

Updates: RFC 4172

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6172

Changes to Fibre Channel have caused the specification of theInternet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified. iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document.
This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre ChannelInternet Protocol (FCIP).

RFC 6173 Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP)

Authors: P. Venkatesen, Ed..

Date: March 2011

Formats: txt html json

Obsoletes: RFC 4369

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6173

This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.
This document obsoletes RFC 4369.

RFC 6174 Definition of IETF Working Group Document States

Authors: E. Juskevicius.

Date: March 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6174

The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.
This document defines new states and status annotation tags that need to be added to the Datatracker to enable WG Chairs and theirDelegates to track the status of Internet-Drafts (I-Ds) that are associated with their WGs. This document also describes the meaning of all previously implemented I-D states and substate annotation tags currently used by IETF Area Directors to indicate the status of I-Ds that have been sent to the IESG for evaluation and publication.

RFC 6175 Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors

Authors: E. Juskevicius.

Date: March 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6175

This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for WorkingGroup (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs. After these requirements are implemented, WG Chairs will be able to use theDatatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible.

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 6177 IPv6 Address Assignment to End Sites

Authors: T. Narten, G. Huston, L. Roberts.

Date: March 2011

Formats: txt html json

Obsoletes: RFC 3177

Also: BCP 0157

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6177

RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005.This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177.Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.
This document obsoletes RFC 3177.

RFC 6178 Label Edge Router Forwarding of IPv4 Option Packets

Authors: D. Smith, J. Mullooly, W. Jaeger, T. Scholl.

Date: March 2011

Formats: txt json html

Updates: RFC 3031

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6178

This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in differentLER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class(FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulateIPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke.

RFC 6179 The Internet Routing Overlay Network (IRON)

Authors: F. Templin, Ed..

Date: March 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6179

Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes anInternet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of theIRTF Routing Research Group.

RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment

Authors: J. Arkko, F. Baker.

Date: May 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6180

The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations.

RFC 6181 Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses

Authors: M. Bagnulo.

Date: March 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6181

Multipath TCP (MPTCP for short) describes the extensions proposed forTCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multipleIP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP.

RFC 6182 Architectural Guidelines for Multipath TCP Development

Authors: A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar.

Date: March 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6182

Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.
This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of aMultipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements.

RFC 6183 IP Flow Information Export (IPFIX) Mediation: Framework

Authors: A. Kobayashi, B. Claise, G. Muenz, K. Ishibashi.

Date: April 2011

Formats: txt html json

Updates: RFC 5470

Status: INFORMATIONAL

DOI: 10.17487/RFC 6183

This document describes a framework for IP Flow Information Export(IPFIX) Mediation. This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components.

RFC 6184 RTP Payload Format for H.264 Video

Authors: Y.-K. Wang, R. Even, T. Kristensen, R. Jesup.

Date: May 2011

Formats: txt json html

Obsoletes: RFC 3984

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6184

This memo describes an RTP Payload format for the ITU-TRecommendation H.264 video codec and the technically identicalISO/IEC International Standard 14496-10 video codec, excluding theScalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere.The RTP payload format allows for packetization of one or moreNetwork Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.
This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15.

RFC 6185 RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video

Authors: T. Kristensen, P. Luthi.

Date: May 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6185

This document describes an RTP payload format for the Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing.The RCDO RTP payload format is based on the H.264 RTP payload format.

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 6187 X.509v3 Certificates for Secure Shell Authentication

Authors: K. Igoe, D. Stebila.

Date: March 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6187

X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol.

RFC 6188 The Use of AES-192 and AES-256 in Secure RTP

Authors: D. McGrew.

Date: March 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6188

This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure RealtimeTransport Control Protocol (SRTCP) and a new SRTP Key DerivationFunction (KDF) for AES-192 and AES-256.

RFC 6189 ZRTP: Media Path Key Agreement for Unicast Secure RTP

Authors: P. Zimmermann, A. Johnston, Ed., J. Callas.

Date: April 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6189

This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume aPublic Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a SessionDescription Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effortSRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles.ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature.

RFC 6190 RTP Payload Format for Scalable Video Coding

Authors: S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis.

Date: May 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6190

This memo describes an RTP payload format for Scalable Video Coding(SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC InternationalStandard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multipleRTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.

RFC 6191 Reducing the TIME-WAIT State Using TCP Timestamps

Authors: F. Gont.

Date: April 2011

Formats: txt json html

Also: BCP 0159

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6191

This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged.

RFC 6192 Protecting the Router Control Plane

Authors: D. Dugal, C. Pignataro, R. Dunn.

Date: March 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6192

This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.
Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router.

RFC 6193 Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)

Authors: M. Saito, D. Wing, M. Toyama.

Date: April 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6193

This document specifies how to establish a media session that represents a virtual private network using the Session InitiationProtocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the SessionDescription Protocol (SDP) so that it can negotiate use of theInternet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate.

RFC 6194 Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms

Authors: T. Polk, L. Chen, S. Turner, P. Hoffman.

Date: March 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6194

This document includes security considerations for the SHA-0 andSHA-1 message digest algorithm.

RFC 6195 Domain Name System (DNS) IANA Considerations

Authors: D. Eastlake 3rd.

Date: March 2011

Formats: txt json html

Obsoletes: RFC 5395

Obsoleted by: RFC 6895

Updates: RFC 1183, RFC 3597

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6195

This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain NameSystem (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.

RFC 6196 Moving mailserver: URI Scheme to Historic

Authors: A. Melnikov.

Date: March 2011

Formats: txt html json

Updates: RFC 1738

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6196

This document registers the mailserver: URI scheme as historic in theIANA URI registry.

RFC 6197 Location-to-Service Translation (LoST) Service List Boundary Extension

Authors: K. Wolf.

Date: April 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6197

Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation&rt; query to the LoST server.However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines aService List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving.

RFC 6198 Requirements for the Graceful Shutdown of BGP Sessions

Authors: B. Decraene, P. Francois, C. Pelsser, Z. Ahmad, A.J. Elizondo Armengol, T. Takeda.

Date: April 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6198

The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic. However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications(e.g., voice over IP, online gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown.This document expresses requirements for such a solution.

RFC 6201 Device Reset Characterization

Authors: R. Asati, C. Pignataro, F. Calabria, C. Olvera.

Date: March 2011

Formats: txt json html

Updates: RFC 1242, RFC 2544

Status: INFORMATIONAL

DOI: 10.17487/RFC 6201

An operational forwarding device may need to be restarted(automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.
This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term "reset time" and, only in this, updates RFC 1242.

RFC 6202 Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP

Authors: S. Loreto, P. Saint-Andre, S. Salsano, G. Wilkins.

Date: April 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6202

On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming.

RFC 6203 IMAP4 Extension for Fuzzy Search

Authors: T. Sirainen.

Date: March 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6203

This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages.

RFC 6204 Basic Requirements for IPv6 Customer Edge Routers

Authors: H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed..

Date: April 2011

Formats: txt json html

Obsoleted by: RFC 7084

Status: INFORMATIONAL

DOI: 10.17487/RFC 6204

This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it.

RFC 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 6206 The Trickle Algorithm

Authors: P. Levis, T. Clausen, J. Hui, O. Gnawali, J. Ko.

Date: March 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6206

The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use.

RFC 6207 The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml

Authors: R. Denenberg, Ed..

Date: April 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6207

This document specifies media types for the following formats: MODS(Metadata Object Description Schema), MADS (Metadata AuthorityDescription Schema), METS (Metadata Encoding and TransmissionStandard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema. These are allXML schemas providing representations of various forms of information including metadata and search results.

RFC 6208 Cloud Data Management Interface (CDMI) Media Types

Authors: K. Sankar, Ed., A. Jones.

Date: April 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6208

This document describes several Internet media types defined for theCloud Data Management Interface (CDMI) by the Storage NetworkingIndustry Association (SNIA). The media types are: o application/cdmi-object o application/cdmi-container o application/cdmi-domain o application/cdmi-capability o application/cdmi-queue

RFC 6209 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)

Authors: W. Kim, J. Lee, J. Park, D. Kwon.

Date: April 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6209

This document specifies a set of cipher suites for the TransportLayer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher.

RFC 6210 Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME

Authors: J. Schaad.

Date: April 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6210

New hash algorithms are being developed that may include parameters.Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems. This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be.

RFC 6211 Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute

Authors: J. Schaad.

Date: April 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6211

The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process.

RFC 6212 Authentication-Results Registration for Vouch by Reference Results

Authors: M. Kucherawy.

Date: April 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6212

This memo updates the registry of properties in Authentication-Results: message header fields to allow relaying of the results of aVouch By Reference query.

RFC 6213 IS-IS BFD-Enabled TLV

Authors: C. Hopps, L. Ginsberg.

Date: April 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6213

This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of theBidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to aBFD-detected forwarding plane failure without use of either this TLV or some other method.

RFC 6214 Adaptation of RFC 1149 for IPv6

Authors: B. Carpenter, R. Hinden.

Date: 1 April 2011

Formats: txt json html

Updates: RFC 1149

Status: INFORMATIONAL

DOI: 10.17487/RFC 6214

This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149.

RFC 6215 MPLS Transport Profile User-to-Network and Network-to-Network Interfaces

Authors: M. Bocci, L. Levrau, D. Frost.

Date: April 2011

Formats: txt json html

Updates: RFC 5921

Status: INFORMATIONAL

DOI: 10.17487/RFC 6215

The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) TransportService Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.
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 6216 Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms

Authors: C. Jennings, K. Ono, R. Sparks, B. Hibbard, Ed..

Date: April 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6216

This document shows example call flows demonstrating the use ofTransport Layer Security (TLS), and Secure/Multipurpose Internet MailExtensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing.

RFC 6217 Regional Broadcast Using an Atmospheric Link Layer

Authors: T. Ritter.

Date: 1 April 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6217

Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan AreaNetworks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment.

RFC 6218 Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material

Authors: G. Zorn, T. Zhang, J. Walker, J. Salowey.

Date: April 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6218

This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message.These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors.

RFC 6219 The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition

Authors: X. Li, C. Bao, M. Chen, H. Zhang, J. Wu.

Date: May 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6219

This document presents the China Education and Research Network(CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.
The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP'sIPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the globalIPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in the CERNET as a reference for the IETF standard documents on IPv4/IPv6 stateless translation.

RFC 6220 Defining the Role and Function of IETF Protocol Parameter Registry Operators

Authors: D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed., Internet Architecture Board.

Date: April 2011

Formats: txt json html

Obsoleted by: RFC 8722

Status: INFORMATIONAL

DOI: 10.17487/RFC 6220

Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions.

RFC 6221 Lightweight DHCPv6 Relay Agent

Authors: D. Miles, Ed., S. Ooghe, W. Dec, S. Krishnan, A. Kavanagh.

Date: May 2011

Formats: txt json html

Updates: RFC 3315

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6221

This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link AccessMultiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions.

RFC 6222 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)

Authors: A. Begen, C. Perkins, D. Wing.

Date: April 2011

Formats: txt html json

Obsoleted by: RFC 7022

Updates: RFC 3550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6222

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While theSynchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCPCNAMEs.

RFC 6223 Indication of Support for Keep-Alive

Authors: C. Holmberg.

Date: April 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6223

This specification defines a new Session Initiation Protocol (SIP)Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network AddressTranslation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation.

RFC 6224 Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains

Authors: T. Schmidt, M. Waehlisch, S. Krishnan.

Date: April 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6224

This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents inMobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. Support for mobile multicast senders is outside the scope of this document.

RFC 6225 Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information

Authors: J. Polk, M. Linsner, M. Thomson, B. Aboba, Ed..

Date: July 2011

Formats: txt json html

Obsoletes: RFC 3825

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6225

This document specifies Dynamic Host Configuration Protocol options(both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includesLatitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825.

RFC 6226 PIM Group-to-Rendezvous-Point Mapping

Authors: B. Joshi, A. Kessler, D. McWalter.

Date: May 2011

Formats: txt html json

Updates: RFC 4601

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6226

Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintainsGroup-to-RP mappings that are used to identify a Rendezvous Point(RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned.
This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group.This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm.

RFC 6227 Design Goals for Scalable Internet Routing

Authors: T. Li, Ed..

Date: May 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6227

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi- homing, and inter-domain traffic engineering. The Routing ResearchGroup is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture.

RFC 6228 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog

Authors: C. Holmberg.

Date: May 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6228

This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities.

RFC 6229 Test Vectors for the Stream Cipher RC4

Authors: J. Strombergson, S. Josefsson.

Date: May 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6229

This document contains test vectors for the stream cipher RC4.

RFC 6230 Media Control Channel Framework

Authors: C. Boulton, T. Melanchuk, S. McGlashan.

Date: May 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6230

This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers.
The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope.

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 6233 IS-IS Registry Extension for Purges

Authors: T. Li, L. Ginsberg.

Date: May 2011

Formats: txt html json

Updates: RFC 3563, RFC 5304, RFC 5310

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6233

IANA maintains the "IS-IS TLV Codepoints" registry. This registry documents which TLVs can appear in different types of IS-IS ProtocolData Units (PDUs), but does not document which TLVs can be found in zero Remaining Lifetime Link State PDUs (LSPs), a.k.a. purges. This document extends the existing registry to record the set of TLVs that are permissible in purges and updates the rules for generating and processing purges in the presence of authentication. This document updates RFC 3563, RFC 5304, and RFC 5310.

RFC 6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)

Authors: D. Eastlake 3rd, T. Hansen.

Date: May 2011

Formats: txt json html

Obsoletes: RFC 4634

Updates: RFC 3174

Status: INFORMATIONAL

DOI: 10.17487/RFC 6234

The United States of America has adopted a suite of Secure HashAlgorithms (SHAs), including four beyond SHA-1, as part of a FederalInformation Processing Standard (FIPS), namely SHA-224, SHA-256,SHA-384, and SHA-512. This document makes open source code performing these SHA hash functions conveniently available to theInternet community. The sample code supports input strings of arbitrary bit length. Much of the text herein was adapted by the authors from FIPS 180-2.
This document replaces RFC 4634, fixing errata and adding code for anHMAC-based extract-and-expand Key Derivation Function, HKDF (RFC5869). As with RFC 4634, code to perform SHA-based Hashed MessageAuthentication Codes (HMACs) is also included.

RFC 6235 IP Flow Anonymization Support

Authors: E. Boschi, B. Trammell.

Date: May 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6235

This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export(IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files.

RFC 6236 Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)

Authors: I. Johansson, K. Jung.

Date: May 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6236

This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a low-end hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted.

RFC 6237 IMAP4 Multimailbox SEARCH Extension

Authors: B. Leiba, A. Melnikov.

Date: May 2011

Formats: txt html json

Obsoleted by: RFC 7377

Updates: RFC 4466

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6237

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT andSEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields inESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466.

RFC 6238 TOTP: Time-Based One-Time Password Algorithm

Authors: D. M'Raihi, S. Machani, M. Pei, J. Rydell.

Date: May 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6238

This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. TheHOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security.
The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access andWi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations.

RFC 6239 Suite B Cryptographic Suites for Secure Shell (SSH)

Authors: K. Igoe.

Date: May 2011

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 6239

This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and theSecure Shell Authentication Protocol. Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the AdvancedEncryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), andX.509 certificates.

RFC 6240 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2

Authors: D. Zelig, Ed., R. Cohen, Ed., T. Nadeau, Ed..

Date: May 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6240

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits over a Packet Switch Network (PSN).

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 6242 Using the NETCONF Protocol over Secure Shell (SSH)

Authors: M. Wasserman.

Date: June 2011

Formats: txt json html

Obsoletes: RFC 4742

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6242

This document describes a method for invoking and running the NetworkConfiguration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742.

RFC 6243 With-defaults Capability for NETCONF

Authors: A. Bierman, B. Lengyel.

Date: June 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6243

The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data.

RFC 6244 An Architecture for Network Management Using NETCONF and YANG

Authors: P. Shafer.

Date: June 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6244

The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities.
This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators.

RFC 6245 Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4

Authors: P. Yegani, K. Leung, A. Lior, K. Chowdhury, J. Navali.

Date: May 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6245

The Generic Routing Encapsulation (GRE) specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new MobileIP extension that is used to exchange the value to be used in the GREKey field. This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile node traffic. The new extension allows a Foreign Agent to requestGRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4. GRE tunneling with the Key field allows the operators to have home networks that consist of multiple VirtualPrivate Networks (VPNs), which may have overlapping home addresses.When the tuple <Care of Address, Home Address, and Home AgentAddress&rt; is the same across multiple subscriber sessions, GRE tunneling will provide a means for the Foreign Agent and Home Agent to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when usingIP-in-IP tunneling.

RFC 6246 Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges

Authors: A. Sajassi, Ed., F. Brockners, D. Mohan, Ed., Y. Serbest.

Date: June 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6246

One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers.
When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in theIEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module andIETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE.

RFC 6247 Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status

Authors: L. Eggert.

Date: May 2011

Formats: txt json html

Obsoletes: RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, RFC 1693

Updates: RFC 4614

Status: INFORMATIONAL

DOI: 10.17487/RFC 6247

This document reclassifies several TCP extensions that have never seen widespread use to Historic status. The affected RFCs are RFC1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, andRFC 1693.

RFC 6248 RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete

Authors: A. Morton.

Date: April 2011

Formats: txt html json

Obsoletes: RFC 4148

Updates: RFC 4737, RFC 5560, RFC 5644, RFC 6049

Status: INFORMATIONAL

DOI: 10.17487/RFC 6248

This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM)Metrics Registry", as Obsolete, and withdraws the IANA IPPM MetricsRegistry itself from use because it is obsolete. The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010.

RFC 6249 Metalink/HTTP: Mirrors and Hashes

Authors: A. Bryan, N. McNab, T. Tsujikawa, P. Poeml, H. Nordstrom.

Date: June 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6249

This document specifies Metalink/HTTP: Mirrors and CryptographicHashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations(mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements forMetalink/HTTP clients and servers are described here.

RFC 6250 Evolution of the IP Model

Authors: D. Thaler.

Date: May 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6250

This RFC attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, especially properties that were(and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed. The discussion of these properties is organized around evaluating a set of claims, or misconceptions. Finally, this document provides some guidance to protocol designers and implementers.

RFC 6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol

Authors: S. Josefsson.

Date: May 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6251

This document specifies how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol in order to provide additional security features.

RFC 6252 A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization

Authors: A. Dutta, Ed., V. Fajardo, Y. Ohba, K. Taniuchi, H. Schulzrinne.

Date: June 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6252

This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover.MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document.
This document is a product of the IP Mobility Optimizations (MOBOPTS)Research Group.

RFC 6253 Host Identity Protocol Certificates

Authors: T. Heer, S. Varjonen.

Date: May 2011

Formats: txt json html

Obsoleted by: RFC 8002

Updates: RFC 5201

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6253

The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in HostIdentity Protocol (HIP) control packets. This document specifies theCERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) andSimple Public Key Infrastructure (SPKI) certificates.
The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter.
This document updates RFC 5201.

RFC 6254 Request to Move RFC 2754 to Historic Status

Authors: M. McFadden.

Date: May 2011

Formats: txt html json

Obsoletes: RFC 2754

Status: INFORMATIONAL

DOI: 10.17487/RFC 6254

RFC 2754 requested that each time IANA made an address assignment, it was to create appropriate inetnum and as-block objects and digitally sign them. The purpose was to distribute the IANA-held public key in software implementations of the Distributed Routing Policy System.In practice, this was never done on the public Internet. This document requests that RFC 2754 be moved to Historic status.

RFC 6255 Delay-Tolerant Networking Bundle Protocol IANA Registries

Authors: M. Blanchet.

Date: May 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6255

The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and LickliderTransmission Protocol. The specifications of these protocols contain fields that are subject to a registry. For the purpose of its research work, the group created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries toIANA for official custody. This document describes the actions executed by IANA.

RFC 6256 Using Self-Delimiting Numeric Values in Protocols

Authors: W. Eddy, E. Davies.

Date: May 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6256

Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols.SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of theDelay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.

RFC 6257 Bundle Security Protocol Specification

Authors: S. Symington, S. Farrell, H. Weiss, P. Lovell.

Date: May 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6257

This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol.Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.
This document is a product of the Delay-Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.

RFC 6258 Delay-Tolerant Networking Metadata Extension Block

Authors: S. Symington.

Date: May 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6258

This document defines an extension block that may be used with theDelay-Tolerant Networking (DTN) Bundle Protocol. This MetadataExtension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as anRFC were raised.

RFC 6259 Delay-Tolerant Networking Previous-Hop Insertion Block

Authors: S. Symington.

Date: May 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6259

This document defines an extension block for use with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Previous-HopInsertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols(e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.

RFC 6260 Compressed Bundle Header Encoding (CBHE)

Authors: S. Burleigh.

Date: May 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6260

This document describes a convention by which Delay-TolerantNetworking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.
Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing.Therefore, it has no impact on the interoperability of differentBundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.
This document is a product of the Delay-Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.

RFC 6261 Encrypted Signaling Transport Modes for the Host Identity Protocol

Authors: A. Keranen.

Date: May 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6261

This document specifies two transport modes for Host IdentityProtocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol.

RFC 6262 RTP Payload Format for IP-MR Speech Codec

Authors: S. Ikonin.

Date: August 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6262

This document specifies the payload format for packetization ofSPIRIT IP-MR encoded speech signals into the Real-time TransportProtocol (RTP). The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors.

RFC 6263 Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows

Authors: X. Marjou, A. Sollaud.

Date: June 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6263

This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP ControlProtocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to InteractiveConnectivity Establishment (ICE) agents.

RFC 6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition

Authors: S. Jiang, D. Guo, B. Carpenter.

Date: June 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6264

Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period.
This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts andIPv4 access services for IPv4 hosts while leaving much of a legacyISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements.

RFC 6265 HTTP State Management Mechanism

Authors: A. Barth.

Date: April 2011

Formats: txt html json

Obsoletes: RFC 2965

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6265

This document defines the HTTP Cookie and Set-Cookie header fields.These header fields can be used by HTTP servers to store state(called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965.

RFC 6266 Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)

Authors: J. Reschke.

Date: June 2011

Formats: txt json html

Updates: RFC 2616

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6266

RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects.

RFC 6267 MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)

Authors: V. Cakulev, G. Sundaram.

Date: June 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6267

This document describes a key management protocol variant for theMultimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service. In particular, this variant utilizesIdentity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework. This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy.

RFC 6268 Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)

Authors: J. Schaad, S. Turner.

Date: July 2011

Formats: txt html json

Updates: RFC 5911

Status: INFORMATIONAL

DOI: 10.17487/RFC 6268

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 some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax.

RFC 6269 Issues with IP Address Sharing

Authors: M. Ford, Ed., M. Boucadair, A. Durand, P. Levis, P. Roberts.

Date: June 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6269

The completion of IPv4 address allocations from IANA and the RegionalInternet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.
Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein.

RFC 6270 The 'tn3270' URI Scheme

Authors: M. Yevstifeyev.

Date: June 2011

Formats: txt html json

Updates: RFC 2355, RFC 1738, RFC 1041

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6270

This document is the specification of the 'tn3270' Uniform ResourceIdentifier (URI) scheme, which is used to designate the access to the resources available via Telnet 3270 mode (TN3270) and Telnet 3270Enhanced mode (TN3270E). It updates RFC 1041 and RFC 2355, which specify these protocols, and RFC 1738, which firstly mentioned thisURI scheme without defining its syntax and semantics.

RFC 6271 Requirements for SIP-Based Session Peering

Authors: J-F. Mule.

Date: June 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6271

This memo captures protocol requirements to enable session peering of voice, presence, instant messaging, and other types of multimedia traffic. This informational document is intended to link the various use cases described for session peering to protocol solutions.

RFC 6272 Internet Protocols for the Smart Grid

Authors: F. Baker, D. Meyer.

Date: June 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6272

This note identifies the key infrastructure protocols of the InternetProtocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriateInternet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for SmartGrid deployment from the picture presented here.

RFC 6273 The Secure Neighbor Discovery (SEND) Hash Threat Analysis

Authors: A. Kukec, S. Krishnan, S. Jiang.

Date: June 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6273

This document analyzes the use of hashes in Secure Neighbor Discovery(SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND.

RFC 6274 Security Assessment of the Internet Protocol Version 4

Authors: F. Gont.

Date: July 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6274

This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI).

RFC 6275 Mobility Support in IPv6

Authors: C. Perkins, Ed., D. Johnson, J. Arkko.

Date: July 2011

Formats: txt html json

Obsoletes: RFC 3775

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6275

This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enablesIPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775.

RFC 6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO)

Authors: R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Bernardos.

Date: July 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6276

One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router for use on the links in the mobile network. This document specifies how DHCPv6 prefix delegation can be used for this configuration task. The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router. When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function.

RFC 6277 Online Certificate Status Protocol Algorithm Agility

Authors: S. Santesson, P. Hallam-Baker.

Date: June 2011

Formats: txt json html

Obsoleted by: RFC 6960

Updates: RFC 2560

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6277

The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported.

RFC 6278 Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax

Authors: J. Herzog, R. Khazan.

Date: June 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6278

This document describes how to use the 'static-static Elliptic CurveDiffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie-Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates.

RFC 6279 Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement

Authors: M. Liebsch, Ed., S. Jeong, Q. Wu.

Date: June 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6279

Proxy Mobile IPv6 is the IETF Standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their LocalMobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy MobileIPv6.

RFC 6280 An Architecture for Location and Location Privacy in Internet Applications

Authors: R. Barnes, M. Lepinski, A. Cooper, J. Morris, H. Tschofenig, H. Schulzrinne.

Date: July 2011

Formats: txt html json

Updates: RFC 3693, RFC 3694

Also: BCP 0160

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6280

Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services.

RFC 6281 Understanding Apple's Back to My Mac (BTMM) Service

Authors: S. Cheshire, Z. Zhu, R. Wakikawa, L. Zhang.

Date: June 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6281

This document describes the implementation of Apple Inc.'s Back to MyMac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators(NATs) and mobility of devices.

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 6283 Extensible Markup Language Evidence Record Syntax (XMLERS)

Authors: A. Jerman Blazic, S. Saljic, T. Gondrom.

Date: July 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6283

In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data. The ExtensibleMarkup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax NotationOne) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML.

RFC 6284 Port Mapping between Unicast and Multicast RTP Sessions

Authors: A. Begen, D. Wing, T. Van Caenegem.

Date: June 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6284

This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client.

RFC 6285 Unicast-Based Rapid Acquisition of Multicast RTP Sessions

Authors: B. Ver Steeg, A. Begen, T. Van Caenegem, Z. Vax.

Date: June 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6285

When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as theAcquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts.
In this document, we describe a method using the existing RTP and RTPControl Protocol (RTCP) machinery that reduces the acquisition delay.In this method, an auxiliary unicast RTP session carrying theReference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition.The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem.

RFC 6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4

Authors: E. Chen, J. Yuan.

Date: June 2011

Formats: txt json html

Updates: RFC 4271

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6286

To accommodate situations where the current requirements for the BGPIdentifier are not met, this document relaxes the definition of theBGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the "uniqueness" requirement so that only Autonomous-System- wide (AS-wide) uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issues. This document updates RFC 4271.

RFC 6287 OCRA: OATH Challenge-Response Algorithm

Authors: D. M'Raihi, J. Rydell, S. Bajaj, S. Machani, D. Naccache.

Date: June 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6287

This document describes an algorithm for challenge-response authentication developed by the Initiative for Open Authentication(OATH). The specified mechanisms leverage the HMAC-based One-TimePassword (HOTP) algorithm and offer one-way and mutual authentication, and electronic signature capabilities.

RFC 6288 URN Namespace for the Defence Geospatial Information Working Group (DGIWG)

Authors: C. Reed.

Date: August 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6288

This document describes the Namespace Identifier (NID) for UniformResource Name (URN) Namespace resources published by the DefenceGeospatial Information Working Group (DGIWG). The DGIWG defines and manages resources that utilize this URN name model.
Management activities for these and other resource types are provided by the DGIWG Registry System (DRS).

RFC 6289 A Uniform Resource Name (URN) Namespace for CableLabs

Authors: E. Cardona, S. Channabasappa, J-F. Mule.

Date: June 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6289

This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs).CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' AssignedNames and Numbers registry.

RFC 6290 A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)

Authors: Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi.

Date: June 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6290

This document describes an extension to the Internet Key ExchangeProtocol version 2 (IKEv2) that allows for faster detection ofSecurity Association (SA) desynchronization using a saved token.
When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart.

RFC 6291 Guidelines for the Use of the "OAM" Acronym in the IETF

Authors: L. Andersson, H. van Helvoort, R. Bonica, D. Romascanu, S. Mansfield.

Date: June 2011

Formats: txt html json

Also: BCP 0161

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6291

At first glance, the acronym "OAM" seems to be well-known and well- understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again.
This document provides a definition of the acronym "OAM" (Operations,Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term.

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 6293 Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker

Authors: P. Hoffman.

Date: June 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6293

The document gives a set of requirements for extending the IETFDatatracker to give individual IETF community members, including theIETF leadership, easy methods for tracking the progress of theInternet-Drafts and RFCs of interest to them.

RFC 6294 Survey of Proposed Use Cases for the IPv6 Flow Label

Authors: Q. Hu, B. Carpenter.

Date: June 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6294

The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised.

RFC 6295 RTP Payload Format for MIDI

Authors: J. Lazzaro, J. Wawrzynek.

Date: June 2011

Formats: txt html json

Obsoletes: RFC 4695

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6295

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including theMIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable SoundsLevel 2, and Structured Audio. This document obsoletes RFC 4695.

RFC 6296 IPv6-to-IPv6 Network Prefix Translation

Authors: M. Wasserman, F. Baker.

Date: June 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6296

This document describes a stateless, transport-agnostic IPv6-to-IPv6Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT(NAPT44) and provides a 1:1 relationship between addresses in the"inside" and "outside" prefixes, preserving end-to-end reachability at the network layer.

RFC 6297 A Survey of Lower-than-Best-Effort Transport Protocols

Authors: M. Welzl, D. Ros.

Date: June 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6297

This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standardTCP than standard TCP itself when they share a bottleneck with it.Such protocols could be used for delay-insensitive "background" traffic, as they provide what is sometimes called a "less than" (or"lower than") best-effort service.

RFC 6298 Computing TCP's Retransmission Timer

Authors: V. Paxson, M. Allman, J. Chu, M. Sargent.

Date: June 2011

Formats: txt html json

Obsoletes: RFC 2988

Updates: RFC 1122

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6298

This document defines the standard algorithm that TransmissionControl Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion inSection 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988.

RFC 6301 A Survey of Mobility Support in the Internet

Authors: Z. Zhu, R. Wakikawa, L. Zhang.

Date: July 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6301

Over the last two decades, many efforts have been devoted to developing solutions for mobility support over the global Internet, resulting in a variety of proposed solutions. We conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support. This document reports our findings and identifies remaining issues in providing ubiquitous and efficient Internet mobility support on a global scale.

RFC 6302 Logging Recommendations for Internet-Facing Servers

Authors: A. Durand, I. Gashinsky, D. Lee, S. Sheppard.

Date: June 2011

Formats: txt json html

Also: BCP 0162

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6302

In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address.

RFC 6303 Locally Served DNS Zones

Authors: M. Andrews.

Date: July 2011

Formats: txt json html

Also: BCP 0163

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6303

Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise.RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC1918 address space and other well-known zones with similar characteristics.

RFC 6304 AS112 Nameserver Operations

Authors: J. Abley, W. Maton.

Date: July 2011

Formats: txt html json

Obsoleted by: RFC 7534

Status: INFORMATIONAL

DOI: 10.17487/RFC 6304

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated inRFC 1918 for private use within individual sites.
Devices in such environments may occasionally originate Domain NameSystem (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.
It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.
This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation.

RFC 6305 I'm Being Attacked by PRISONER.IANA.ORG!

Authors: J. Abley, W. Maton.

Date: July 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6305

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated inRFC 1918 for private use within individual sites.
Hosts should never normally send DNS reverse-mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely coordinated effort known as the AS112 project.
Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected.Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked.
This document provides background information and technical advice to those firewall operators.

RFC 6306 Hierarchical IPv4 Framework

Authors: P. Frejborg.

Date: July 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6306

This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique.In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet.
This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing DomainName System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers.

RFC 6307 Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks

Authors: D. Black, Ed., L. Dunbar, Ed., M. Roth, R. Solomon.

Date: April 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6307

A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of MPLS to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service.

RFC 6308 Overview of the Internet Multicast Addressing Architecture

Authors: P. Savola.

Date: June 2011

Formats: txt html json

Obsoletes: RFC 2908

Status: INFORMATIONAL

DOI: 10.17487/RFC 6308

The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use.

RFC 6309 IANA Rules for MIKEY (Multimedia Internet KEYing)

Authors: J. Arkko, A. Keranen, J. Mattsson.

Date: August 2011

Formats: txt html json

Obsoletes: RFC 4909

Updates: RFC 3830, RFC 4563, RFC 5410, RFC 6043

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6309

This document clarifies and relaxes the IANA rules for MultimediaInternet KEYing (MIKEY). This document updates RFCs 3830, 4563,5410, and 6043; it obsoletes RFC 4909.

RFC 6310 Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping

Authors: M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, Y(J). Stein.

Date: July 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6310

This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior ofProvider Edges (PEs) with respect to PW and AC defects. It addressesATM, Frame Relay, Time Division Multiplexing (TDM), and SynchronousOptical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs).

RFC 6311 Protocol Support for High Availability of IKEv2/IPsec

Authors: R. Singh, Ed., G. Kalyani, Y. Nir, Y. Sheffer, D. Zhang.

Date: July 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6311

The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsecHigh Availability (HA) clusters. However, there are many issues inIPsec HA clustering, and in particular in Internet Key ExchangeProtocol version 2 (IKEv2) clustering. An earlier document, "IPsecCluster Problem Statement", enumerates the issues encountered in theIKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.
This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization ofIKEv2 Message ID counters, and of IPsec replay counters.

RFC 6312 Mobile Networks Considerations for IPv6 Deployment

Authors: R. Koodli.

Date: July 2011

Formats: txt json html

Obsoleted by: RFC 6342

Status: INFORMATIONAL

DOI: 10.17487/RFC 6312

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers.

RFC 6313 Export of Structured Data in IP Flow Information Export (IPFIX)

Authors: B. Claise, G. Dhandapani, P. Aitken, S. Yates.

Date: July 2011

Formats: txt json html

Updates: RFC 5102

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6313

This document specifies an extension to the IP Flow InformationExport (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record.

RFC 6314 NAT Traversal Practices for Client-Server SIP

Authors: C. Boulton, J. Rosenberg, G. Camarillo, F. Audet.

Date: July 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6314

Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently, there are many deployment scenarios and traversal mechanisms for media traffic. This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows.

RFC 6315 IANA Registration for Enumservice 'iax'

Authors: E. Guy, K. Darilion.

Date: July 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6315

This document registers an Enumservice for the Inter-Asterisk eXchange (IAX) protocol according to the guidelines given in RFC6117.

RFC 6316 Sockets Application Program Interface (API) for Multihoming Shim

Authors: M. Komu, M. Bagnulo, K. Slavov, S. Sugimoto, Ed..

Date: July 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6316

This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.
This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter called "shim sub- layer") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are Shim6 and theHost Identity Protocol (HIP).

RFC 6317 Basic Socket Interface Extensions for the Host Identity Protocol (HIP)

Authors: M. Komu, T. Henderson.

Date: July 2011

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6317

This document defines extensions to the current sockets API for theHost Identity Protocol (HIP). The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags(HITs) and locators. With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies.

RFC 6318 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)

Authors: R. Housley, J. Solinas.

Date: June 2011

Formats: txt html json

Obsoletes: RFC 5008

Status: HISTORIC

DOI: 10.17487/RFC 6318

This document specifies the conventions for using the United StatesNational Security Agency's Suite B algorithms in Secure/MultipurposeInternet Mail Extensions (S/MIME) as specified in RFC 5751. This document obsoletes RFC 5008.

RFC 6319 Issues Associated with Designating Additional Private IPv4 Address Space

Authors: M. Azinger, L. Vegoda.

Date: July 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6319

When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of privateIPv4 address space.
While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered.

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 6322 Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams

Authors: P. Hoffman.

Date: July 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6322

This document describes extending the IETF Datatracker to capture and display the progression of Internet-Drafts that are intended to be published as RFCs by the IAB, IRTF, or Independent SubmissionsEditor. The states and annotations that are to be added to theDatatracker will be applied to Internet-Drafts as soon as any of these streams identify the Internet-Draft as a potential eventualRFC, and will continue through the lifetime of the Internet-Draft.The goal of adding this information to the Datatracker is to give the whole Internet community more information about the status of theseInternet-Drafts and the streams from which they originate.

RFC 6323 Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)

Authors: G. Renker, G. Fairhurst.

Date: July 2011

Formats: txt json html

Updates: RFC 4342, RFC 5622

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6323

This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol(DCCP). It updates specifications for the CCID-3 and CCID-4Congestion Control IDs of DCCP.
The update addresses parameter-estimation problems occurring withTFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender.
It is integrated into the feature set of DCCP as an end-to-end negotiable extension.

RFC 6324 Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations

Authors: G. Nakibly, F. Templin.

Date: August 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6324

This document is concerned with security vulnerabilities in IPv6-in-IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration.

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 6326 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS

Authors: D. Eastlake, A. Banerjee, D. Dutt, R. Perlman, A. Ghanwani.

Date: July 2011

Formats: txt json html

Obsoleted by: RFC 7176

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6326

The IETF has standardized the Transparent Interconnection of Lots ofLinks (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing.This document specifies the data formats and code points for theIS-IS extensions to support TRILL.

RFC 6327 Routing Bridges (RBridges): Adjacency

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 6328 IANA Considerations for Network Layer Protocol Identifiers

Authors: D. Eastlake 3rd.

Date: July 2011

Formats: txt html json

Also: BCP 0164

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6328

Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization /International Electrotechnical Commission) Network Layer ProtocolIdentifier (NLPID). This document provides NLPID IANA considerations.

RFC 6329 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging

Authors: D. Fedyk, Ed., P. Ashwood-Smith, Ed., D. Allan, A. Bragg, P. Unbehagen.

Date: April 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6329

802.1aq Shortest Path Bridging (SPB) has been standardized by theIEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths. This permits it to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multipoint, and multipoint-to-multipoint variations. This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples.

RFC 6330 RaptorQ Forward Error Correction Scheme for Object Delivery

Authors: M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, L. Minder.

Date: August 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6330

This document describes a Fully-Specified Forward Error Correction(FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects.
RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required.
The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated.

RFC 6331 Moving DIGEST-MD5 to Historic

Authors: A. Melnikov.

Date: July 2011

Formats: txt html json

Obsoletes: RFC 2831

Status: INFORMATIONAL

DOI: 10.17487/RFC 6331

This memo describes problems with the DIGEST-MD5 SimpleAuthentication and Security Layer (SASL) mechanism as specified inRFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry ofSASL mechanisms and moves RFC 2831 to Historic status.

RFC 6332 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)

Authors: A. Begen, E. Friedrich.

Date: July 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6332

In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies.Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called theMulticast Acquisition (MA) report block, within the framework of RTPControl Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP).

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 6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite

Authors: D. Hankins, T. Mrugalski.

Date: August 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6334

This document specifies a DHCPv6 option that is meant to be used by aDual-Stack Lite Basic Bridging BroadBand (B4) element to discover theIPv6 address of its corresponding Address Family Transition Router(AFTR).

RFC 6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry

Authors: M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire.

Date: August 2011

Formats: txt html json

Updates: RFC 2780, RFC 2782, RFC 3828, RFC 4340, RFC 4960, RFC 5595

Also: BCP 0165

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6335

This document defines the procedures that the Internet AssignedNumbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol PortNumber registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.
This document updates IANA's procedures by obsoleting the previousUDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the DatagramCongestion Control Protocol (DCCP), and the Stream ControlTransmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered.

RFC 6336 IANA Registry for Interactive Connectivity Establishment (ICE) Options

Authors: M. Westerlund, C. Perkins.

Date: July 2011

Formats: txt json html

Obsoleted by: RFC 8839

Updates: RFC 5245

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6336

It has been identified that "Interactive Connectivity Establishment(ICE): A Protocol for Network Address Translator (NAT) Traversal forOffer/Answer Protocols" (RFC 5245) is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC 5245.

RFC 6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model

Authors: S. Okumura, T. Sawada, P. Kyzivat.

Date: August 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6337

The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the SessionDescription Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication.

RFC 6338 Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC)

Authors: V. Giralt, R. McDuff.

Date: August 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6338

This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC).
The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes.

RFC 6339 Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API)

Authors: S. Josefsson, L. Hornquist Astrand.

Date: August 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6339

This document describes three abstract Generic Security ServiceApplication Program Interface (GSS-API) interfaces used to encapsulate/decapsulate context tokens and compare OIDs. This document also specifies C bindings for the abstract interfaces.

RFC 6340 Textual Conventions for the Representation of Floating-Point Numbers

Authors: R. Presuhn.

Date: August 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6340

This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers.

RFC 6341 Use Cases and Requirements for SIP-Based Media Recording (SIPREC)

Authors: K. Rehor, Ed., L. Portman, Ed., A. Hutton, R. Jain.

Date: August 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6341

Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics.
Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based MediaRecording.

RFC 6342 Mobile Networks Considerations for IPv6 Deployment

Authors: R. Koodli.

Date: August 2011

Formats: txt html json

Obsoletes: RFC 6312

Status: INFORMATIONAL

DOI: 10.17487/RFC 6342

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers.

RFC 6343 Advisory Guidelines for 6to4 Deployment

Authors: B. Carpenter.

Date: August 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6343

This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to ContentProviders. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls.

RFC 6344 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)

Authors: G. Bernstein, Ed., D. Caviglia, R. Rabbat, H. van Helvoort.

Date: August 2011

Formats: txt json html

Updates: RFC 4606

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6344

This document describes requirements for, and the use of, theGeneralized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link CapacityAdjustment Scheme (LCAS). LCAS can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply toOptical Transport Network (OTN), Synchronous Optical Network (SONET),Synchronous Digital Hierarchy (SDH), and Plesiochronous DigitalHierarchy (PDH) signals. This document updates RFC 4606 by making modifications to the procedures for supporting virtual concatenation.

RFC 6345 Protocol for Carrying Authentication for Network Access (PANA) Relay Element

Authors: P. Duffy, S. Chakrabarti, R. Cragie, Y. Ohba, Ed., A. Yegin.

Date: August 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6345

This document specifies Protocol for carrying Authentication forNetwork Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent(PAA) where the two nodes cannot reach each other by means of regularIP routing.

RFC 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage

Authors: R. Bush, Ed..

Date: August 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6346

We are facing the exhaustion of the IANA IPv4 free IP address pool.Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.
This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face ofIPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core.

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 6348 Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol

Authors: JL. Le Roux, Ed., T. Morin, Ed..

Date: September 2011

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 6348

This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over aMultiprotocol Label Switching (MPLS) infrastructure.
This work was overtaken by the protocol solution developed by theMPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work.

RFC 6349 Framework for TCP Throughput Testing

Authors: B. Constantine, G. Forget, R. Geib, R. Schrage.

Date: August 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6349

This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network. The goal is to provide a better indication in regard to user experience. In this framework, TCP and IP parameters are specified to optimize TCPThroughput.

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 6354 Forward-Shifted RTP Redundancy Payload Support

Authors: Q. Xie.

Date: August 2011

Formats: txt json html

Updates: RFC 2198, RFC 4102

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6354

This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media).

RFC 6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)

Authors: T. Narten, J. Johnson.

Date: August 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6355

This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID. DUID-UUIDs are derived from the already- standardized Universally Unique IDentifier (UUID) format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves toDHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP.

RFC 6356 Coupled Congestion Control for Multipath Transport Protocols

Authors: C. Raiciu, M. Handley, D. Wischik.

Date: October 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6356

Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.
New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.
This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links.

RFC 6357 Design Considerations for Session Initiation Protocol (SIP) Overload Control

Authors: V. Hilt, E. Noel, C. Shen, A. Abdelal.

Date: August 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6357

Overload occurs in Session Initiation Protocol (SIP) networks whenSIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism.

RFC 6358 Additional Master Secret Inputs for TLS

Authors: P. Hoffman.

Date: January 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6358

This document describes a mechanism for using additional master secret inputs with Transport Layer Security (TLS) and Datagram TLS(DTLS).

RFC 6359 Datatracker Extensions to Include IANA and RFC Editor Processing Information

Authors: S. Ginoza, M. Cotton, A. Morris.

Date: September 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6359

This document captures the requirements for integrating IANA and RFCEditor state information into the Datatracker to provide the community with a unified tool to track the status of their document as it progresses from Internet-Draft (I-D) version -00 to RFC.Extending the Datatracker to hold document data from I-D version -00 to RFC allows for increased automation between the Datatracker, IANA, and RFC Editor, thus reducing manual labor, processing errors, and potential delay. Therefore, this document also describes the requirements to make such automation possible.

RFC 6360 Conclusion of FYI RFC Sub-Series

Authors: R. Housley.

Date: August 2011

Formats: txt json html

Obsoletes: RFC 1150

Status: INFORMATIONAL

DOI: 10.17487/RFC 6360

This document concludes the For Your Information (FYI) sub-series ofRFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists. The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision. This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic.

RFC 6361 PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol

Authors: J. Carlson, D. Eastlake 3rd.

Date: August 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6361

The Point-to-Point Protocol (PPP) defines a Link Control Protocol(LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) viaPPP links.

RFC 6362 Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT)

Authors: K. Meadors, Ed..

Date: August 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6362

The Electronic Data Interchange - Internet Integration (EDIINT) AS1,AS2, and AS3 messages were designed specifically for the transport ofEDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDIINT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This Informational RFC describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDIINT transport message. The attachments are stored within the MIME multipart/related structure. A minimal list of content-types to be supported as attachments is provided.

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 6364 Session Description Protocol Elements for the Forward Error Correction (FEC) Framework

Authors: A. Begen.

Date: October 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6364

This document specifies the use of the Session Description Protocol(SDP) to describe the parameters required to signal the Forward ErrorCorrection (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework.

RFC 6365 Terminology Used in Internationalization in the IETF

Authors: P. Hoffman, J. Klensin.

Date: September 2011

Formats: txt json html

Obsoletes: RFC 3536

Also: BCP 0166

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6365

This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.

RFC 6366 Requirements for an Internet Audio Codec

Authors: J. Valin, K. Vos.

Date: August 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6366

This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties.

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 6369 Forwarding and Control Element Separation (ForCES) Implementation Experience

Authors: E. Haleplidis, O. Koufopavlou, S. Denazis.

Date: September 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6369

The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a ForwardingElement (FE). This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing theForCES protocol.

RFC 6370 MPLS Transport Profile (MPLS-TP) Identifiers

Authors: M. Bocci, G. Swallow, E. Gray.

Date: September 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6370

This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP).The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations,Administration, and Maintenance (OAM) functions compatible with IP/MPLS conventions.
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 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 6372 MPLS Transport Profile (MPLS-TP) Survivability Framework

Authors: N. Sprecher, Ed., A. Farrel, Ed..

Date: September 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6372

Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources.Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements(SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.
This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance(OAM) functions. This document describes mechanisms for recoveringMPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond 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-based transport network as defined by the ITU-T.

RFC 6373 MPLS Transport Profile (MPLS-TP) Control Plane Framework

Authors: L. Andersson, Ed., L. Berger, Ed., L. Fang, Ed., N. Bitar, Ed., E. Gray, Ed..

Date: September 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6373

The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management- plane functions are out of 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 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 6375 A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks

Authors: D. Frost, Ed., S. Bryant, Ed..

Date: September 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6375

Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374.
The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks.
This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP.
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 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 6377 DomainKeys Identified Mail (DKIM) and Mailing Lists

Authors: M. Kucherawy.

Date: September 2011

Formats: txt html json

Also: BCP 0167

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6377

DomainKeys Identified Mail (DKIM) allows an ADministrative ManagementDomain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers(MLMs).

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 6379 Suite B Cryptographic Suites for IPsec

Authors: L. Law, J. Solinas.

Date: October 2011

Formats: txt json html

Obsoletes: RFC 4869

Status: HISTORIC

DOI: 10.17487/RFC 6379

This document proposes four cryptographic user interface suites("UI suites") for IP Security (IPsec), similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This document obsoletes RFC 4869, which presented earlier versions of these suites.

RFC 6380 Suite B Profile for Internet Protocol Security (IPsec)

Authors: K. Burgin, M. Peck.

Date: October 2011

Formats: txt json html

Status: HISTORIC

DOI: 10.17487/RFC 6380

The United States Government has published guidelines for "NSASuite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IPSecurity (IPsec).
Since many of the Suite B algorithms are used in other environments, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant detail repeated to aid developers who choose to support Suite B.

RFC 6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types

Authors: R. Gellens, D. Singer, P. Frojdh.

Date: August 2011

Formats: txt json html

Obsoletes: RFC 4281

Updates: RFC 3839, RFC 4393, RFC 4337

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6381

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content-Type alone if the content can be rendered.
This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document.
By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action(such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.).
Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies.This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean.

RFC 6382 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services

Authors: D. McPherson, R. Donnelly, F. Scalzo.

Date: October 2011

Formats: txt html json

Also: BCP 0169

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6382

This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment.

RFC 6383 Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE

Authors: K. Shiomoto, A. Farrel.

Date: September 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6383

The Resource Reservation Protocol (RSVP) has been extended to supportTraffic Engineering (TE) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives.
End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.
This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices.

RFC 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation

Authors: I. van Beijnum.

Date: October 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6384

The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers,FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are stillIPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent.
FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch.

RFC 6385 General Area Review Team (Gen-ART) Experiences

Authors: M. Barnes, A. Doria, H. Alvestrand, B. Carpenter.

Date: October 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6385

The General Area Review Team (Gen-ART) has been doing reviews ofInternet-Drafts (I-Ds) since 2004. This document discusses the experience and the lessons learned over the past 7 years of this process. The review team initially reviewed the I-Ds before each of the IESG telechats. Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF LastCall is necessary for the I-D. The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda.

RFC 6386 VP8 Data Format and Decoding Guide

Authors: J. Bankoski, J. Koleszar, L. Quillio, J. Salonen, P. Wilkins, Y. Xu.

Date: November 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6386

This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format.

RFC 6387 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)

Authors: A. Takacs, L. Berger, D. Caviglia, D. Fedyk, J. Meuric.

Date: September 2011

Formats: txt html json

Obsoletes: RFC 5467

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6387

This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The approach presented is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467.

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 6389 MPLS Upstream Label Assignment for LDP

Authors: R. Aggarwal, JL. Le Roux.

Date: November 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6389

This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label SwitchingRouter (LSR) traffic replication on a LAN for LDP point-to-multipoint(P2MP) Label Switched Paths (LSPs).

RFC 6390 Guidelines for Considering New Performance Metric Development

Authors: A. Clark, B. Claise.

Date: October 2011

Formats: txt json html

Also: BCP 0170

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6390

This document describes a framework and a process for developingPerformance Metrics of protocols and applications transported overIETF-specified protocols. These metrics can be used to characterize traffic on live networks and services.

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 6392 A Survey of In-Network Storage Systems

Authors: R. Alimi, Ed., A. Rahman, Ed., Y. Yang, Ed..

Date: October 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6392

This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupledApplication Data Enroute) architecture.

RFC 6393 Moving RFC 4693 to Historic

Authors: M. Yevstifeyev.

Date: September 2011

Formats: txt html json

Obsoletes: RFC 4693

Status: INFORMATIONAL

DOI: 10.17487/RFC 6393

This document moves RFC 4693 to Historic status. It also obsoletesRFC 4693.

RFC 6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)

Authors: R. Barnes.

Date: October 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6394

Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name.Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSecurity Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names.

RFC 6395 An Interface Identifier (ID) Hello Option for PIM

Authors: S. Gulrajani, S. Venaas.

Date: October 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6395

This document defines a new PIM Hello option to advertise anInterface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router.

RFC 6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format

Authors: L. Blunk, M. Karir, C. Labovitz.

Date: October 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6396

This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threadedRouting Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents.

RFC 6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions

Authors: T. Manderson.

Date: October 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6397

This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to include optional terrestrial coordinates of a BGP collector and its BGP peers.

RFC 6398 IP Router Alert Considerations and Usage

Authors: F. Le Faucheur, Ed..

Date: October 2011

Formats: txt json html

Updates: RFC 2113, RFC 2711

Also: BCP 0168

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6398

The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. TheResource reSerVation Protocol (RSVP), Pragmatic General Multicast(PGM), the Internet Group Management Protocol (IGMP), MulticastListener Discovery (MLD), Multicast Router Discovery (MRD), andGeneral Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the currentIP Router Alert Option, thereby updating RFC 2113 and RFC 2711.Specifically, it provides recommendations against using the RouterAlert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines forRouter Alert implementation on routers.

RFC 6401 RSVP Extensions for Admission Priority

Authors: F. Le Faucheur, J. Polk, K. Carlberg.

Date: October 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6401

Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol(RSVP) that can be used to support such an admission priority capability at the network layer.
Based on current security concerns, these extensions are intended for use in a single administrative domain.

RFC 6402 Certificate Management over CMS (CMC) Updates

Authors: J. Schaad.

Date: November 2011

Formats: txt html json

Updates: RFC 5272, RFC 5273, RFC 5274

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6402

This document contains a set of updates to the base syntax for CMC, aCertificate Management protocol using the Cryptographic MessageSyntax (CMS). This document updates RFC 5272, RFC 5273, and RFC5274.
The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject InformationAccess value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on.

RFC 6403 Suite B Profile of Certificate Management over CMS

Authors: L. Zieglar, S. Turner, M. Peck.

Date: November 2011

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 6403

The United States government has published guidelines for "NSASuite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates. This profile is a refinement of RFCs 5272, 5273, and 5274.

RFC 6404 Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures

Authors: J. Seedorf, S. Niccolini, E. Chen, H. Scholz.

Date: November 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6404

The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group (WG) provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP Service Providers (SSPs). The objective of this document is to identify and enumerate SPEERMINT- specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. Security requirements forSPEERMINT that have been derived from the threats detailed in this document can be found in RFC 6271; this document provides concrete countermeasures to meet those SPEERMINT security requirements. In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), theLocation Routing Function (LRF), the Signaling Function (SF), and theMedia Function (MF) of a specific SIP Service Provider. Various instances of the threats are briefly introduced inside the classification. Finally, existing security solutions for SIP andRTP/RTCP (Real-time Transport Control Protocol) are presented to describe countermeasures currently available for such threats. EachSSP may have connections to one or more remote SSPs through peering or transit contracts. A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs.

RFC 6405 Voice over IP (VoIP) SIP Peering Use Cases

Authors: A. Uzelac, Ed., Y. Lee, Ed..

Date: November 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6405

This document depicts many common Voice over IP (VoIP) use cases forSession Initiation Protocol (SIP) peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today.

RFC 6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture

Authors: D. Malas, Ed., J. Livingood, Ed..

Date: November 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6406

This document defines a peering architecture for the SessionInitiation Protocol (SIP) and its functional components and interfaces. It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains.

RFC 6407 The Group Domain of Interpretation

Authors: B. Weis, S. Rowles, T. Hardjono.

Date: October 2011

Formats: txt html json

Obsoletes: RFC 3547

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6407

This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547.

RFC 6408 Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage

Authors: M. Jones, J. Korhonen, L. Morand.

Date: November 2011

Formats: txt json html

Updates: RFC 3588

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6408

The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol.However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates RFC 3588, "Diameter Base Protocol", and describes an improvement using an extended format for the Straightforward-NamingAuthority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand.

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 6410 Reducing the Standards Track to Two Maturity Levels

Authors: R. Housley, D. Crocker, E. Burger.

Date: October 2011

Formats: txt json html

Updates: RFC 2026

Also: BCP 0009

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6410

This document updates the Internet Engineering Task Force (IETF)Standards Process defined in RFC 2026. Primarily, it reduces theStandards Process from three Standards Track maturity levels to two.

RFC 6411 Applicability of Keying Methods for RSVP Security

Authors: M. Behringer, F. Le Faucheur, B. Weis.

Date: October 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6411

The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. This document also discusses applicability of encrypting RSVP messages.

RFC 6412 Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence

Authors: S. Poretsky, B. Imhoff, K. Michielsen.

Date: November 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6412

This document describes the terminology for benchmarking link-stateInterior Gateway Protocol (IGP) route convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The terminology can be applied to any link-state IGP, such as IS-IS andOSPF.

RFC 6413 Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence

Authors: S. Poretsky, B. Imhoff, K. Michielsen.

Date: November 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6413

This document describes the methodology for benchmarking Link-StateInterior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The methodology can be applied to any link-state IGP, such as IS-IS andOSPF.

RFC 6414 Benchmarking Terminology for Protection Performance

Authors: S. Poretsky, R. Papneja, J. Karthik, S. Vapiwala.

Date: November 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6414

This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms.The performance benchmarks are measured at the IP layer; protection may be provided at the sub-IP layer. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS),Virtual Router Redundancy Protocol (VRRP), Stateful High Availability(HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR).

RFC 6415 Web Host Metadata

Authors: E. Hammer-Lahav, Ed., B. Cook.

Date: October 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6415

This specification describes a method for locating host metadata as well as information about individual resources controlled by the host.

RFC 6416 RTP Payload Format for MPEG-4 Audio/Visual Streams

Authors: M. Schmidt, F. de Bont, S. Doehla, J. Kim.

Date: October 2011

Formats: txt html json

Obsoletes: RFC 3016

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6416

This document describes Real-time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. This document obsoletes RFC3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision ofRFC 3016 in order to correct misalignments with the 3GPP Packet- switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio.
For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC3016 is provided to update and complete the specification and to enable interoperable implementations.

RFC 6417 How to Contribute Research Results to Internet Standardization

Authors: P. Eardley, L. Eggert, M. Bagnulo, R. Winter.

Date: November 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6417

The development of new technology is driven by scientific research.The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of theInternet originate in the related academic research communities.Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community.
For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly.

RFC 6418 Multiple Interfaces and Provisioning Domains Problem Statement

Authors: M. Blanchet, P. Seite.

Date: November 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6418

This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes.

RFC 6419 Current Practices for Multiple-Interface Hosts

Authors: M. Wasserman, P. Seite.

Date: November 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6419

An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context.

RFC 6420 PIM Multi-Topology ID (MT-ID) Join Attribute

Authors: Y. Cai, H. Ou.

Date: November 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6420

This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree.

RFC 6421 Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)

Authors: D. Nelson, Ed..

Date: November 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6421

This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS).

RFC 6422 Relay-Supplied DHCP Options

Authors: T. Lemon, Q. Wu.

Date: December 2011

Formats: txt html json

Updates: RFC 3315

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6422

DHCPv6 relay agents cannot communicate with DHCPv6 clients directly.However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client.
This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients.

RFC 6423 Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)

Authors: H. Li, L. Martini, J. He, F. Huang.

Date: November 2011

Formats: txt html json

Updates: RFC 5586

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6423

This document describes the requirements for using the GenericAssociated Channel Label (GAL) in pseudowires (PWs) in MPLS TransportProfile (MPLS-TP) networks, and provides an update to the description of GAL usage in RFC 5586 by removing the restriction that is imposed on using GAL for PWs, especially in MPLS-TP environments.

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 6425 Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping

Authors: S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, T. Nadeau.

Date: November 2011

Formats: txt json html

Updates: RFC 4379

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6425

Recent proposals have extended the scope of Multiprotocol LabelSwitching (MPLS) Label Switched Paths (LSPs) to encompass point-to- multipoint (P2MP) LSPs.
The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".
The scope of this document is fault detection and isolation for P2MPMPLS LSPs. This documents does not replace any of the mechanisms ofLSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.
This document updates RFC 4379.

RFC 6426 MPLS On-Demand Connectivity Verification and Route Tracing

Authors: E. Gray, N. Bahadur, S. Boutros, R. Aggarwal.

Date: November 2011

Formats: txt html json

Updates: RFC 4379

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6426

Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths(LSPs). This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLSTransport Profile (MPLS-TP) LSPs and pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP ping to perform connectivity verification and route tracing functions inMPLS-TP networks. Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry.

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 6429 TCP Sender Clarification for Persist Condition

Authors: M. Bashyam, M. Jethanandani, A. Ramaiah.

Date: December 2011

Formats: txt json html

Obsoleted by: RFC 9293

Status: INFORMATIONAL

DOI: 10.17487/RFC 6429

This document clarifies the Zero Window Probes (ZWPs) described inRFC 1122 ("Requirements for Internet Hosts -- Communication Layers").In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified inRFC 1122.

RFC 6430 Email Feedback Report Type Value: not-spam

Authors: K. Li, B. Leiba.

Date: November 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6430

This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report an email message that was mistakenly marked as spam.

RFC 6431 Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)

Authors: M. Boucadair, P. Levis, G. Bajko, T. Savolainen, T. Tsou.

Date: November 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6431

This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes.

RFC 6432 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses

Authors: R. Jesske, L. Liess.

Date: November 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6432

Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326, its use is not specified for any particular response code. Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 cause codes in SIP responses to INVITE requests that have been gatewayed to Public Switched Telephone Network (PSTN) systems. This document normatively describes the use of the Reason header field in carrying Q.850 cause codes in SIP responses.

RFC 6433 Requirements for a Working Group Milestones Tool

Authors: P. Hoffman.

Date: November 2011

Formats: txt html json

Updates: RFC 6292

Status: INFORMATIONAL

DOI: 10.17487/RFC 6433

The IETF intends to provide a new tool to Working Group chairs andArea Directors for the creation and updating of milestones forWorking Group charters. 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. This document updates RFC 6292.

RFC 6434 IPv6 Node Requirements

Authors: E. Jankiewicz, J. Loughney, T. Narten.

Date: December 2011

Formats: txt json html

Obsoletes: RFC 4294

Obsoleted by: RFC 8504

Status: INFORMATIONAL

DOI: 10.17487/RFC 6434

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
This document obsoletes RFC 4294.

RFC 6435 MPLS Transport Profile Lock Instruct and Loopback Functions

Authors: S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed..

Date: November 2011

Formats: txt json html

Updates: RFC 6371

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6435

Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data.
This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.
This document updates Sections 7.1.1 and 7.1.2 of RFC 6371.

RFC 6436 Rationale for Update to the IPv6 Flow Label Specification

Authors: S. Amante, B. Carpenter, S. Jiang.

Date: November 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6436

Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697.Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility.

RFC 6437 IPv6 Flow Label Specification

Authors: S. Amante, B. Carpenter, S. Jiang, J. Rajahalme.

Date: November 2011

Formats: txt html json

Obsoletes: RFC 3697

Updates: RFC 2205, RFC 2460

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6437

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document.
The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.

RFC 6438 Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels

Authors: B. Carpenter, S. Amante.

Date: November 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6438

The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic.

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 6440 The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option

Authors: G. Zorn, Q. Wu, Y. Wang.

Date: December 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6440

In order to derive a Domain-Specific Root Key (DSRK) from theExtended Master Session Key (EMSK) generated as a side effect of anExtensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached.
This document specifies a Dynamic Host Configuration ProtocolVersion 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP.

RFC 6441 Time to Remove Filters for Previously Unallocated IPv4 /8s

Authors: L. Vegoda.

Date: November 2011

Formats: txt html json

Also: BCP 0171

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6441

It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile, and expensive. Network administrators are advised to remove filters based on the registration status of the address space.
This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet.

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 6444 Location Hiding: Problem Statement and Requirements

Authors: H. Schulzrinne, L. Liess, H. Tschofenig, B. Stark, A. Kuett.

Date: January 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6444

The emergency services architecture developed in the IETF EmergencyContext Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point(PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned.
This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or theInternet Service Provider (ISP) are only willing to disclose limited or no location information.

RFC 6445 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute

Authors: T. Nadeau, Ed., A. Koushik, Ed., R. Cetin, Ed..

Date: November 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6445

This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based traffic engineering (TE). The two methods are the one-to-one backup method and the facility backup method.

RFC 6446 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control

Authors: A. Niemi, K. Kiss, S. Loreto.

Date: January 2012

Formats: txt json html

Updates: RFC 3265

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6446

This document specifies mechanisms for adjusting the rate of SessionInitiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265.

RFC 6447 Filtering Location Notifications in the Session Initiation Protocol (SIP)

Authors: R. Mahy, B. Rosen, H. Tschofenig.

Date: January 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6447

This document describes filters that limit asynchronous location notifications to compelling events. These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package.The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format LocationObject (PIDF-LO).

RFC 6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message

Authors: R. Yount.

Date: November 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6448

The Kerberos 5 KRB-CRED message is used to transfer Kerberos credentials between applications. When used with a secure transport, the unencrypted form of the KRB-CRED message may be desirable. This document describes the unencrypted form of the KRB-CRED message.

RFC 6449 Complaint Feedback Loop Operational Recommendations

Authors: J. Falk, Ed..

Date: November 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6449

Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.
This document is the result of cooperative efforts within theMessaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work.

RFC 6450 Multicast Ping Protocol

Authors: S. Venaas.

Date: December 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6450

The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information, such as multicast tree setup time. This protocol is based on an implementation of tools called "ssmping" and "asmping".

RFC 6451 Location-to-Service Translation (LoST) Protocol Extensions

Authors: A. Forte, H. Schulzrinne.

Date: December 2011

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6451

An important class of location-based services answers the question,"What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X", and "served by".

RFC 6452 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0

Authors: P. Faltstrom, Ed., P. Hoffman, Ed..

Date: November 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6452

This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode6.0.

RFC 6453 A URN Namespace for the Open Grid Forum (OGF)

Authors: F. Dijkstra, R. Hughes-Jones.

Date: December 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6453

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Grid Forum (OGF) for naming persistent resources.

RFC 6454 The Web Origin Concept

Authors: A. Barth.

Date: December 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6454

This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request.

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 6456 Multi-Segment Pseudowires in Passive Optical Networks

Authors: H. Li, R. Zheng, A. Farrel.

Date: November 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6456

This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising aPassive Optical Network (PON) and an MPLS Packet Switched Network(PSN).
PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of pseudowire (PW) TerminatingProvider Edge (T-PE) nodes. The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager.
This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (G-PON) or10 Gigabit-capable Passive Optical Network (XG-PON) using the G-PON and XG-PON management protocol, Optical Network TerminationManagement and Control Interface (OMCI). This simplifies and speeds up PW provisioning compared with manual configuration.
This document also shows how an MS-PW may be constructed from an end segment supported over a PON, and switched to one or more segments supported over an MPLS PSN.

RFC 6457 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering

Authors: T. Takeda, Ed., A. Farrel.

Date: December 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6457

The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS(GMPLS).
MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements.
Generic requirements for a communication protocol between PathComputation Clients (PCCs) and PCEs are presented in RFC 4657, "PathComputation Element (PCE) Communication Protocol GenericRequirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element(PCE) Discovery".
This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering.

RFC 6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)

Authors: R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich.

Date: December 2011

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6458

This document describes a mapping of the Stream Control TransmissionProtocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features, and a consolidated error and event notification scheme.

RFC 6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)

Authors: J. Korhonen, Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila.

Date: January 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6459

The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rdGeneration Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures.

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 6461 Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements

Authors: S. Channabasappa, Ed..

Date: January 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6461

This document captures the use cases and associated requirements for interfaces that provision session establishment data into SessionInitiation Protocol (SIP) Service Provider components to assist with session routing. Specifically, this document focuses on the provisioning of one such element termed the "registry".

RFC 6462 Report from the Internet Privacy Workshop

Authors: A. Cooper.

Date: January 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6462

On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society(ISOC), and MIT's Computer Science and Artificial IntelligenceLaboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protectiveInternet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps.For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL.

RFC 6463 Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6

Authors: J. Korhonen, Ed., S. Gundavelli, H. Yokota, X. Cui.

Date: February 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6463

This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy MobileIPv6. The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor. The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load- balancing purposes.

RFC 6464 A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication

Authors: J. Lennox, Ed., E. Ivov, E. Marocco.

Date: December 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6464

This document defines a mechanism by which packets of Real-timeTransport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received.

RFC 6465 A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication

Authors: E. Ivov, Ed., E. Marocco, Ed., J. Lennox.

Date: December 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6465

This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to.

RFC 6466 IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)

Authors: G. Salgueiro.

Date: December 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6466

This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the SessionDescription Protocol (SDP). This media type is primarily used by SDP to negotiate and establish T.38 media streams.

RFC 6467 Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)

Authors: T. Kivinen.

Date: December 2011

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6467

This document defines a generic way for Internet Key Exchange version2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods.

RFC 6468 Sieve Notification Mechanism: SIP MESSAGE

Authors: A. Melnikov, B. Leiba, K. Li.

Date: February 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6468

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE.

RFC 6469 RTP Payload Format for DV (IEC 61834) Video

Authors: K. Kobayashi, K. Mishima, S. Casner, C. Bormann.

Date: December 2011

Formats: txt html json

Obsoletes: RFC 3189

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6469

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189.

RFC 6470 Network Configuration Protocol (NETCONF) Base Notifications

Authors: A. Bierman.

Date: February 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6470

The Network Configuration Protocol (NETCONF) provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events, such as a change in NETCONF server capabilities, that may impact management applications.Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines aYANG module that allows a NETCONF client to receive notifications for some common system events.

RFC 6471 Overview of Best Email DNS-Based List (DNSBL) Operational Practices

Authors: C. Lewis, M. Sergeant.

Date: January 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6471

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering.This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam.

RFC 6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP

Authors: W. Kumari, K. Sriram.

Date: December 2011

Formats: txt json html

Also: BCP 0172

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6472

This document recommends against the use of the AS_SET andAS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group.

RFC 6473 vCard KIND:application

Authors: P. Saint-Andre.

Date: December 2011

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6473

This document defines a value of "application" for the vCard KIND property so that vCards can be used to represent software applications.

RFC 6474 vCard Format Extensions: Place of Birth, Place and Date of Death

Authors: K. Li, B. Leiba.

Date: December 2011

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6474

The base vCard 4.0 specification defines a large number of properties, including date of birth. This specification adds three new properties to vCard 4.0: place of birth, place of death, and date of death.

RFC 6475 Proxy Mobile IPv6 Management Information Base

Authors: G. Keeni, K. Koide, S. Gundavelli, R. Wakikawa.

Date: May 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6475

This memo defines a portion of the Proxy Mobile IPv6 ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, the Proxy Mobile IPv6 MIB can be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6(PMIPv6) entity.

RFC 6476 Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)

Authors: P. Gutmann.

Date: January 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6476

This document specifies the conventions for using MessageAuthentication Code (MAC) encryption with the Cryptographic MessageSyntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security(SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community.

RFC 6477 Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail

Authors: A. Melnikov, G. Lunt.

Date: January 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6477

A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHSElements of Service are defined as a set of extensions to the ITU-TX.400 (1992) international standards and are specified in STANAG 4406Edition 2 and ACP 123. This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service. In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion.

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 6479 IPsec Anti-Replay Algorithm without Bit Shifting

Authors: X. Zhang, T. Tsou.

Date: January 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6479

This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) andEncapsulating Security Protocol (ESP). The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted.

RFC 6480 An Infrastructure to Support Secure Internet Routing

Authors: M. Lepinski, S. Kent.

Date: February 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6480

This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space andAutonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise theRPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters.

RFC 6481 A Profile for Resource Certificate Repository Structure

Authors: G. Huston, R. Loomans, G. Michaelson.

Date: February 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6481

This document defines a profile for the structure of the ResourcePublic Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates,Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction.

RFC 6482 A Profile for Route Origin Authorizations (ROAs)

Authors: M. Lepinski, S. Kent, D. Kong.

Date: February 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6482

This document defines a standard profile for Route OriginAuthorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block.

RFC 6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)

Authors: G. Huston, G. Michaelson.

Date: February 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6483

This document defines the semantics of a Route Origin Authorization(ROA) in terms of the context of an application of the ResourcePublic Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol.

RFC 6484 Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)

Authors: S. Kent, D. Kong, K. Seo, R. Watro.

Date: February 2012

Formats: txt html json

Also: BCP 0173

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6484

This document describes the certificate policy for a Public KeyInfrastructure (PKI) used to support attestations about InternetNumber Resource (INR) holdings. Each organization that distributesIP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources.

RFC 6485 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)

Authors: G. Huston.

Date: February 2012

Formats: txt html json

Obsoleted by: RFC 7935

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6485

This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate RevocationLists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures.

RFC 6486 Manifests for the Resource Public Key Infrastructure (RPKI)

Authors: R. Austein, G. Huston, S. Kent, M. Lepinski.

Date: February 2012

Formats: txt json html

Obsoleted by: RFC 9286

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6486

This document defines a "manifest" for use in the Resource Public KeyInfrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate,Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects.

RFC 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 6488 Signed Object Template for the Resource Public Key Infrastructure (RPKI)

Authors: M. Lepinski, A. Chi, S. Kent.

Date: February 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6488

This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format.

RFC 6489 Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)

Authors: G. Huston, G. Michaelson, S. Kent.

Date: February 2012

Formats: txt html json

Also: BCP 0174

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6489

This document describes how a Certification Authority (CA) in theResource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs.

RFC 6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator

Authors: G. Huston, S. Weiler, G. Michaelson, S. Kent.

Date: February 2012

Formats: txt html json

Obsoleted by: RFC 7730

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6490

This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI).

RFC 6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA

Authors: T. Manderson, L. Vegoda, S. Kent.

Date: February 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6491

This document provides specific direction to IANA as to the ResourcePublic Key Infrastructure (RPKI) objects it should issue.

RFC 6492 A Protocol for Provisioning Resource Certificates

Authors: G. Huston, R. Loomans, B. Ellacott, R. Austein.

Date: February 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6492

This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties.The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework.

RFC 6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record

Authors: R. Bush.

Date: February 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6493

In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI GhostbustersRecord containing human contact information that may be verified(indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard.

RFC 6494 Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)

Authors: R. Gagliano, S. Krishnan, A. Kukec.

Date: February 2012

Formats: txt html json

Updates: RFC 3971

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6494

SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND.

RFC 6495 Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields

Authors: R. Gagliano, S. Krishnan, A. Kukec.

Date: February 2012

Formats: txt html json

Updates: RFC 3971

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6495

SEcure Neighbor Discovery (SEND) defines the Name Type field in theICMPv6 Trust Anchor option. This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKIs).

RFC 6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)

Authors: S. Krishnan, J. Laganier, M. Bonola, A. Garcia-Martinez.

Date: February 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6496

SEcure Neighbor Discovery (SEND) specifies a method for securingNeighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation.

RFC 6497 BCP 47 Extension T - Transformed Content

Authors: M. Davis, A. Phillips, Y. Umaoka, C. Falk.

Date: February 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6497

This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source. It also provides for additional information used for identification.

RFC 6498 Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package

Authors: J. Stone, R. Kumar, F. Andreasen.

Date: February 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6498

This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from Voiceband Data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to defining these new packages, this document describes the use of the Media Format Parameter package andFax package with VBD, redundancy, and FEC.

RFC 6501 Conference Information Data Model for Centralized Conferencing (XCON)

Authors: O. Novo, G. Camarillo, D. Morgan, J. Urpalainen.

Date: March 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6501

RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an XML- based conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in theSession Initiation Protocol (SIP) event package for conference State.

RFC 6502 Conference Event Package Data Format Extension for Centralized Conferencing (XCON)

Authors: G. Camarillo, S. Srinivasan, R. Even, J. Urpalainen.

Date: March 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6502

This document specifies the notification mechanism for XCON(centralized conferencing). This mechanism reuses the SIP (SessionInitiation Protocol) event package for conference state.Additionally, the notification mechanism includes support for theXCON data model and for partial notifications.

RFC 6503 Centralized Conferencing Manipulation Protocol

Authors: M. Barnes, C. Boulton, S. Romano, H. Schulzrinne.

Date: March 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6503

The Centralized Conferencing Manipulation Protocol (CCMP) allows aCentralized Conferencing (XCON) system client to create, retrieve, change, and delete objects that describe a centralized conference.CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema.

RFC 6504 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples

Authors: M. Barnes, L. Miniero, R. Presta, S P. Romano.

Date: March 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6504

This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC5239) and in the XCON scenarios (RFC 4597). The call flows document the use of the interface between a conference control client and a conference control server using the Centralized ConferencingManipulation Protocol (CCMP) (RFC 6503). The objective is to provide detailed examples for reference by both protocol researchers and developers.

RFC 6505 A Mixer Control Package for the Media Control Channel Framework

Authors: S. McGlashan, T. Melanchuk, C. Boulton.

Date: March 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6505

This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers.

RFC 6506 Supporting Authentication Trailer for OSPFv3

Authors: M. Bhatia, V. Manral, A. Lindem.

Date: February 2012

Formats: txt json html

Obsoleted by: RFC 7166

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6506

Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2,Intermediate System to Intermediate System (IS-IS), RIP, and RoutingInformation Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication.

RFC 6507 Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)

Authors: M. Groves.

Date: February 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6507

Many signature schemes currently in use rely on certificates for authentication of identity. In Identity-based cryptography, this adds unnecessary overhead and administration. The Elliptic Curve- based Certificateless Signatures for Identity-based Encryption(ECCSI) signature scheme described in this document is certificateless. This scheme has the additional advantages of low bandwidth and low computational requirements.

RFC 6508 Sakai-Kasahara Key Encryption (SAKKE)

Authors: M. Groves.

Date: February 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6508

In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described. This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver.

RFC 6509 MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)

Authors: M. Groves.

Date: February 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6509

This document describes the Multimedia Internet KEYing-Sakai-KasaharaKey Encryption (MIKEY-SAKKE), a method of key exchange that usesIdentity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication. MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery.

RFC 6510 Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects

Authors: L. Berger, G. Swallow.

Date: February 2012

Formats: txt html json

Updates: RFC 4875, RFC 5420

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6510

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions may be signaled with a set of LSP- specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420.

RFC 6511 Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths

Authors: Z. Ali, G. Swallow, R. Aggarwal.

Date: February 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6511

There are many deployment scenarios that require an egress LabelSwitching Router (LSR) to receive binding of the Resource ReservationProtocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band"(OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to- multipoint (P2MP) LSPs.

RFC 6512 Using Multipoint LDP When the Backbone Has No Route to the Root

Authors: IJ. Wijnands, E. Rosen, M. Napierala, N. Leymann.

Date: February 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6512

The control protocol used for constructing Point-to-Multipoint andMultipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of aBGP-free core. This document specifies procedures that enable an MPLSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node.

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 6515 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN

Authors: R. Aggarwal, E. Rosen.

Date: February 2012

Formats: txt html json

Updates: RFC 6514

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6515

To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN")BGP routes; they also originate unicast VPN routes that carry MVPN- specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses.To ensure interoperability, this document specifies that providerIPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates RFC 6514.

RFC 6516 IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages

Authors: Y. Cai, E. Rosen, Ed., I. Wijnands.

Date: February 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6516

The specification for Multicast Virtual Private Networks (MVPNs) contains an option that allows the use of PIM as the control protocol between provider edge routers. It also contains an option that allows UDP-based messages, known as Selective Provider MulticastService Interface (S-PMSI) Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification (RFC 6513) so that these options can be used when the customer multicast flows are IPv6 flows.

RFC 6517 Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution

Authors: T. Morin, Ed., B. Niven-Jenkins, Ed., Y. Kamite, R. Zhang, N. Leymann, N. Bitar.

Date: February 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6517

More that one set of mechanisms to support multicast in a layer 3BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks.
To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option.

RFC 6518 Keying and Authentication for Routing Protocols (KARP) Design Guidelines

Authors: G. Lebovitz, M. Bhatia.

Date: February 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6518

This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity.

RFC 6519 RADIUS Extensions for Dual-Stack Lite

Authors: R. Maglione, A. Durand.

Date: February 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6519

Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-StackLite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication,Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic HostConfiguration Protocol (DHCP). This document specifies a new RemoteAuthentication Dial-In User Service (RADIUS) attribute to carry theDual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and theNetwork Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server.

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 6521 Home Agent-Assisted Route Optimization between Mobile IPv4 Networks

Authors: A. Makela, J. Korhonen.

Date: February 2012

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6521

This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity. The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes.

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 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration

Authors: R. Stewart, M. Tuexen, P. Lei.

Date: February 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6525

Many applications that use the Stream Control Transmission Protocol(SCTP) want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want it so that they can "reuse" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers.

RFC 6526 IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream

Authors: B. Claise, P. Aitken, A. Johnson, G. Muenz.

Date: March 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6526

This document specifies an extension to the specifications in RFC5101, IP Flow Information Export (IPFIX), when using the PartialReliability extension of SCTP (PR-SCTP, Partial Reliability StreamControl Transmission Protocol).
When implemented at both the Exporting Process and CollectingProcess, this method offers several advantages, such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of TemplateIDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting Process or Exporting Process, then normal IPFIX behavior will be seen without all of the additional benefits.

RFC 6527 Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3)

Authors: K. Tata.

Date: March 2012

Formats: txt json html

Obsoletes: RFC 2787

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6527

This specification defines a portion of the Management InformationBase (MIB) for use with network management based on the SimpleNetwork Management Protocol (SNMP). In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC2787.

RFC 6528 Defending against Sequence Number Attacks

Authors: F. Gont, S. Bellovin.

Date: February 2012

Formats: txt html json

Obsoletes: RFC 1948

Obsoleted by: RFC 9293

Updates: RFC 0793

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6528

This document specifies an algorithm for the generation of TCPInitial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793.

RFC 6529 Host/Host Protocol for the ARPA Network

Authors: A. McKenzie, S. Crocker.

Date: April 2012

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 6529

This document reproduces the Host/Host Protocol developed by the ARPANetwork Working Group during 1969, 1970, and 1971. It describes a protocol used to manage communication between processes residing on independent Hosts. It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface. It was the official protocol of theARPA Network from January 1972 until the switch to TCP/IP in January1983. It is offered as an RFC at this late date to help complete the historical record available through the RFC series.

RFC 6530 Overview and Framework for Internationalized Email

Authors: J. Klensin, Y. Ko.

Date: February 2012

Formats: txt html json

Obsoletes: RFC 4952, RFC 5504, RFC 5825

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6530

Full use of electronic mail throughout the world requires that(subject to other constraints) people be able to use close variations on 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. This document is a replacement for RFC4952; it reflects additional issues identified since that document was published.

RFC 6531 SMTP Extension for Internationalized Email

Authors: J. Yao, W. Mao.

Date: February 2012

Formats: txt html json

Obsoletes: RFC 5336

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6531

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information.

RFC 6532 Internationalized Email Headers

Authors: A. Yang, S. Steele, N. Freed.

Date: February 2012

Formats: txt json html

Obsoletes: RFC 5335

Updates: RFC 2045

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6532

Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.
This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/".

RFC 6533 Internationalized Delivery Status and Disposition Notifications

Authors: T. Hansen, Ed., C. Newman, A. Melnikov.

Date: February 2012

Formats: txt json html

Obsoletes: RFC 5337

Updates: RFC 3461, RFC 3464, RFC 3798, RFC 6522

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6533

Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards(RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.
This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522.

RFC 6534 Loss Episode Metrics for IP Performance Metrics (IPPM)

Authors: N. Duffield, A. Morton, J. Sommers.

Date: May 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6534

The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts.However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured.

RFC 6535 Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)

Authors: B. Huang, H. Deng, T. Savolainen.

Date: February 2012

Formats: txt html json

Obsoletes: RFC 2767, RFC 3338

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6535

Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 andRFC 3338.

RFC 6536 Network Configuration Protocol (NETCONF) Access Control Model

Authors: A. Bierman, M. Bjorklund.

Date: March 2012

Formats: txt json html

Obsoleted by: RFC 8341

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6536

The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model.

RFC 6537 Host Identity Protocol Distributed Hash Table Interface

Authors: J. Ahrenholz.

Date: February 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6537

This document specifies a common interface for using the HostIdentity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host-Identity-Tag-to-address lookup service.

RFC 6538 The Host Identity Protocol (HIP) Experiment Report

Authors: T. Henderson, A. Gurtov.

Date: March 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6538

This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures.

RFC 6539 IBAKE: Identity-Based Authenticated Key Exchange

Authors: V. Cakulev, G. Sundaram, I. Broustis.

Date: March 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6539

Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure(PKI) to support certificate management. The emerging field ofIdentity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility. However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. This document specifies the Identity-Based Authenticated Key Exchange(IBAKE) protocol. IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy.

RFC 6540 IPv6 Support Required for All IP-Capable Nodes

Authors: W. George, C. Donley, C. Liljenstolpe, L. Howard.

Date: April 2012

Formats: txt json html

Also: BCP 0177

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6540

Given the global lack of available IPv4 space, and limitations inIPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, orIPv4-only, depending on context and application.

RFC 6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures

Authors: M. Kucherawy.

Date: February 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6541

This experimental specification proposes a modification to DomainKeysIdentified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author.

RFC 6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility

Authors: S. Emery.

Date: March 2012

Formats: txt html json

Updates: RFC 4121

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6542

Currently, channel bindings are implemented using an MD5 hash in theKerberos Version 5 Generic Security Service Application ProgrammingInterface (GSS-API) mechanism (RFC 4121). This document updates RFC4121 to allow channel bindings using algorithms negotiated based onKerberos crypto framework as defined in RFC 3961. In addition, because this update makes use of the last extensible field in theKerberos client-server exchange message, extensions are defined to allow future protocol extensions.

RFC 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6

Authors: S. Gundavelli.

Date: May 2012

Formats: txt html json

Updates: RFC 5213

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6543

Proxy Mobile IPv6 (RFC 5213) requires that all mobile access gateways use a fixed link-local address and a fixed link-layer address on any of their access links that they share with mobile nodes. This requirement was intended to ensure that a mobile node does not detect any change with respect to its Layer 3 attachment, even after it roams from one mobile access gateway to another. In the absence of any reserved addresses for this use, coordination across vendors and manual configuration of these addresses on all of the mobility elements in a Proxy Mobile IPv6 domain are required. This document attempts to simplify this operational requirement by making a reservation for special addresses that can be used for this purpose.This document also updates RFC 5213.

RFC 6544 TCP Candidates with Interactive Connectivity Establishment (ICE)

Authors: J. Rosenberg, A. Keranen, B. B. Lowekamp, A. B. Roach.

Date: March 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6544

Interactive Connectivity Establishment (ICE) defines a mechanism forNAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on SessionTraversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams.This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream.

RFC 6545 Real-time Inter-network Defense (RID)

Authors: K. Moriarty.

Date: April 2012

Formats: txt json html

Obsoletes: RFC 6045

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6545

Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC6045.

RFC 6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS

Authors: B. Trammell.

Date: April 2012

Formats: txt html json

Obsoletes: RFC 6046

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6546

The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-networkDefense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies an application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS.

RFC 6547 RFC 3627 to Historic Status

Authors: W. George.

Date: February 2012

Formats: txt html json

Obsoletes: RFC 3627

Updates: RFC 6164

Status: INFORMATIONAL

DOI: 10.17487/RFC 6547

This document moves "Use of /127 Prefix Length Between RoutersConsidered Harmful" (RFC 3627) to Historic status to reflect the updated guidance contained in "Using 127-Bit IPv6 Prefixes on Inter-Router Links" (RFC 6164). A Standards Track document supersedes an informational document; therefore, guidance provided in RFC 6164 is to be followed when the two documents are in conflict. This document links the two RFCs so that the IETF's updated guidance on this topic is clearer.

RFC 6548 Independent Submission Editor Model

Authors: N. Brownlee, Ed., IAB.

Date: June 2012

Formats: txt json html

Obsoletes: RFC 5620

Obsoleted by: RFC 8730

Status: INFORMATIONAL

DOI: 10.17487/RFC 6548

This document describes the function and responsibilities of the RFCIndependent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC ProductionCenter and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF AdministrativeOversight Committee (IAOC).

RFC 6549 OSPFv2 Multi-Instance Extensions

Authors: A. Lindem, A. Roy, S. Mirtorabi.

Date: March 2012

Formats: txt json html

Updates: RFC 2328

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6549

OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet.
This document defines the OSPFv2 Instance ID to enable separateOSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances.
This document updates RFC 2328.

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 6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks

Authors: JP. Vasseur, Ed., M. Kim, Ed., K. Pister, N. Dejean, D. Barthel.

Date: March 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6551

Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL).

RFC 6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)

Authors: P. Thubert, Ed..

Date: March 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6552

The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specificObjective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPLInstance based on the Information Objects available; an OF is not an algorithm.
This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions.

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 6554 An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)

Authors: J. Hui, JP. Vasseur, D. Culler, V. Manral.

Date: March 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6554

In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The RoutingProtocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., theDirected Acyclic Graph (DAG) root) or a few routers and forward theIPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a newIPv6 Routing header type for delivering datagrams within a RPL routing domain.

RFC 6555 Happy Eyeballs: Success with Dual-Stack Hosts

Authors: D. Wing, A. Yourtchenko.

Date: April 2012

Formats: txt json html

Obsoleted by: RFC 8305

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6555

When a server's IPv4 path and protocol are working, but the server'sIPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to anIPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm.

RFC 6556 Testing Eyeball Happiness

Authors: F. Baker.

Date: April 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6556

The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering.This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it.

RFC 6557 Procedures for Maintaining the Time Zone Database

Authors: E. Lear, P. Eggert.

Date: February 2012

Formats: txt html json

Also: BCP 0175

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6557

Time zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Time Zone(TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world. This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire. This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community. The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers.

RFC 6558 Sieve Extension for Converting Messages before Delivery

Authors: A. Melnikov, B. Leiba, K. Li.

Date: March 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6558

This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery.

RFC 6559 A Reliable Transport Mechanism for PIM

Authors: D. Farinacci, IJ. Wijnands, S. Venaas, M. Napierala.

Date: March 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6559

This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing.The reliable transport mechanism can use either TCP or SCTP as the transport protocol.

RFC 6560 One-Time Password (OTP) Pre-Authentication

Authors: G. Richards.

Date: April 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6560

The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One-Time Password(OTP) authentication.

RFC 6561 Recommendations for the Remediation of Bots in ISP Networks

Authors: J. Livingood, N. Mody, M. O'Reirdan.

Date: March 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6561

This document contains recommendations on how Internet ServiceProviders can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers. Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud. Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular InternetService Provider's network.

RFC 6562 Guidelines for the Use of Variable Bit Rate Audio with Secure RTP

Authors: C. Perkins, JM. Valin.

Date: March 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6562

This memo discusses potential security issues that arise when using variable bit rate (VBR) audio with the secure RTP profile.Guidelines to mitigate these issues are suggested.

RFC 6563 Moving A6 to Historic Status

Authors: S. Jiang, D. Conrad, B. Carpenter.

Date: March 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6563

This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators.

RFC 6564 A Uniform Format for IPv6 Extension Headers

Authors: S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland, M. Bhatia.

Date: April 2012

Formats: txt json html

Updates: RFC 2460

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6564

In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport- layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed.

RFC 6565 OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol

Authors: P. Pillay-Esnault, P. Moyer, J. Doyle, E. Ertekin, M. Lundberg.

Date: June 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6565

Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge(CE) routers are routing peers of Provider Edge (PE) routers. TheBorder Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and MultiprotocolLabel Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6VPNs; however, only Open Shortest Path First version 2 (OSPFv2) asPE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that ofOSPFv2 except for the differences described in this document.

RFC 6566 A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments

Authors: Y. Lee, Ed., G. Bernstein, Ed., D. Li, G. Martinelli.

Date: March 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6566

As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks.
This document provides a framework for applying GMPLS protocols and the Path Computation Element (PCE) architecture to supportImpairment-Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios, and architectural processes: routing, wavelength assignment, and impairment validation.This document does not define optical data plane aspects; impairment parameters; or measurement of, or assessment and qualification of, a route; rather, it describes the architectural and information components for protocol solutions.

RFC 6567 Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP

Authors: A. Johnston, L. Liess.

Date: April 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6567

This document introduces the transport of call control User-to-UserInformation (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application.This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the Integrated Services Digital Network(ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI.

RFC 6568 Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

Authors: E. Kim, D. Kaspar, JP. Vasseur.

Date: April 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6568

This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications.A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN Working Group is provided with the characteristics of each dimension. A complete list of practical use cases is not the goal of this document.

RFC 6569 Guidelines for Development of an Audio Codec within the IETF

Authors: JM. Valin, S. Borilin, K. Vos, C. Montgomery, R. Chen.

Date: March 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6569

This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues.

RFC 6570 URI Template

Authors: J. Gregorio, R. Fielding, M. Hadley, M. Nottingham, D. Orchard.

Date: March 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6570

A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion.This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet.

RFC 6571 Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks

Authors: C. Filsfils, Ed., P. Francois, Ed., M. Shand, B. Decraene, J. Uttaro, N. Leymann, M. Horneffer.

Date: June 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6571

In this document, we analyze the applicability of the Loop-FreeAlternate (LFA) method of providing IP fast reroute in both the core and access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network.

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 6573 The Item and Collection Link Relations

Authors: M. Amundsen.

Date: April 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6573

RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members.

RFC 6574 Report from the Smart Object Workshop

Authors: H. Tschofenig, J. Arkko.

Date: April 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6574

This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on 'Interconnecting Smart Objects with theInternet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet EngineeringTask Force (IETF) community.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 6575 Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs

Authors: H. Shah, Ed., E. Rosen, Ed., G. Heron, Ed., V. Kompella, Ed..

Date: June 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6575

The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge(CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs). In general, the AttachmentCircuits must be of the same technology (e.g., both Ethernet or bothATM), and the pseudowire must carry the frames of that technology.However, if it is known that the frames' payload consists solely ofIP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as"Address Resolution Protocol (ARP) Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP.

RFC 6576 IP Performance Metrics (IPPM) Standard Advancement Testing

Authors: R. Geib, Ed., A. Morton, R. Fardid, A. Steinmitz.

Date: March 2012

Formats: txt html json

Also: BCP 0176

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6576

This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way. This is the performance-metric equivalent of interoperability, required to advance RFCs along theStandards Track. Results from different implementations of metricRFCs will be collected under the same underlying network conditions and compared using statistical methods. The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track. This document is anInternet Best Current Practice.

RFC 6577 Authentication-Results Registration Update for Sender Policy Framework (SPF) Results

Authors: M. Kucherawy.

Date: March 2012

Formats: txt html json

Obsoleted by: RFC 7001

Updates: RFC 5451

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6577

This memo updates the registry of authentication method results inAuthentication-Results: message header fields, correcting a discontinuity between the original registry creation and the SenderPolicy Framework (SPF) specification.
This memo updates RFC 5451.

RFC 6578 Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)

Authors: C. Daboo, A. Quillaud.

Date: March 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6578

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection.

RFC 6579 The 'disclosure' Link Relation Type

Authors: M. Yevstifeyev.

Date: March 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6579

This document specifies the 'disclosure' link relation type. It designates a list of IPR disclosures made with respect to the material for which such a relation type is specified.

RFC 6580 IANA Registries for the Remote Direct Data Placement (RDDP) Protocols

Authors: M. Ko, D. Black.

Date: April 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6580

The original RFCs that specified the Remote Direct Data Placement(RDDP) protocol suite did not create IANA registries for RDDP error codes, operation codes, and function codes. Extensions to the RDDP protocols now require these registries to be created. This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries.

RFC 6581 Enhanced Remote Direct Memory Access (RDMA) Connection Establishment

Authors: A. Kanevsky, Ed., C. Bestler, Ed., R. Sharp, S. Wise.

Date: April 2012

Formats: txt json html

Updates: RFC 5043, RFC 5044

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6581

This document updates RFC 5043 and RFC 5044 by extending MarkerProtocol Data Unit (PDU) Aligned Framing (MPA) negotiation for RemoteDirect Memory Access (RDMA) connection establishment. The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA / Transmission Control Protocol (TCP). The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration.

RFC 6582 The NewReno Modification to TCP's Fast Recovery Algorithm

Authors: T. Henderson, S. Floyd, A. Gurtov, Y. Nishida.

Date: April 2012

Formats: txt html json

Obsoletes: RFC 3782

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6582

RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as"NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782.

RFC 6583 Operational Neighbor Discovery Problems

Authors: I. Gashinsky, J. Jaeggli, W. Kumari.

Date: March 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6583

In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of NeighborDiscovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.
This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks.

RFC 6584 Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols

Authors: V. Roca.

Date: April 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6584

This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented ReliableMulticast (NORM) protocols. The first scheme is based on RSA DigitalSignatures. The second scheme relies on the Elliptic Curve DigitalSignature Algorithm (ECDSA). The third scheme relies on a Group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service.

RFC 6585 Additional HTTP Status Codes

Authors: M. Nottingham, R. Fielding.

Date: April 2012

Formats: txt json html

Updates: RFC 2616

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6585

This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations.

RFC 6586 Experiences from an IPv6-Only Network

Authors: J. Arkko, A. Keranen.

Date: April 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6586

This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments.

RFC 6587 Transmission of Syslog Messages over TCP

Authors: R. Gerhards, C. Lonvick.

Date: April 2012

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 6587

There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice.This memo describes how TCP has been used as a transport for syslog messages.

RFC 6588 A URN Namespace for ucode

Authors: C. Ishikawa.

Date: April 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6588

This document describes a Uniform Resource Name (URN) namespace for ucode, an identifier system for objects and places. ucode technology is used in many applications, and this document provides a URN namespace for ucode to enable its use in Internet-related devices and software.

RFC 6589 Considerations for Transitioning Content to IPv6

Authors: J. Livingood.

Date: April 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6589

This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers.

RFC 6590 Redaction of Potentially Sensitive Data from Mail Abuse Reports

Authors: J. Falk, Ed., M. Kucherawy, Ed..

Date: April 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6590

Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively.

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 6592 The Null Packet

Authors: C. Pignataro.

Date: 1 April 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6592

The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined. This memo corrects that omission.

RFC 6593 Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS)

Authors: C. Pignataro, J. Clarke, G. Salgueiro.

Date: 1 April 2012

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6593

With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence.Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.
This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment.

RFC 6594 Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records

Authors: O. Sury.

Date: April 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6594

This document updates the IANA registries in RFC 4255, which definesSSHFP, a DNS Resource Record (RR) that contains a standard SecureShell (SSH) key fingerprint used to verify SSH host keys using DNSSecurity Extensions (DNSSEC). This document defines additional options supporting SSH public keys applying the Elliptic CurveDigital Signature Algorithm (ECDSA) and the implementation of fingerprints computed using the SHA-256 message digest algorithm inSSHFP Resource Records.

RFC 6595 A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML)

Authors: K. Wierenga, E. Lear, S. Josefsson.

Date: April 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6595

The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. The Simple Authentication andSecurity Layer (SASL) and the Generic Security Service ApplicationProgram Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAMLIdentity Providers with applications using SASL and GSS-API.

RFC 6596 The Canonical Link Relation

Authors: M. Ohye, J. Kupke.

Date: April 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6596

RFC 5988 specifies a way to define relationships between links on the web. This document describes a new type of such a relationship,"canonical", to designate an Internationalized Resource Identifier(IRI) as preferred over resources with duplicative content.

RFC 6597 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data

Authors: J. Downs, Ed., J. Arbeiter, Ed..

Date: April 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6597

This document specifies the payload format for packetization of KLV(Key-Length-Value) Encoded Data, as defined by the Society of MotionPicture and Television Engineers (SMPTE) in SMPTE ST 336, into theReal-time Transport Protocol (RTP).

RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space

Authors: J. Weil, V. Kuarsingh, C. Donley, C. Liljenstolpe, M. Azinger.

Date: April 2012

Formats: txt json html

Updates: RFC 5735

Also: BCP 0153

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6598

This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier-Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).
Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks.However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document.
This document details the allocation of an additional special-useIPv4 address block and updates RFC 5735.

RFC 6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks

Authors: G. Ash, Ed., D. McDysan.

Date: April 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6601

This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress.Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers.MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv- aware MPLS Traffic Engineering (DS-TE), Path Computation Element(PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF. The MPLSGCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic.

RFC 6602 Bulk Binding Update Support for Proxy Mobile IPv6

Authors: F. Abinader, Ed., S. Gundavelli, Ed., K. Leung, S. Krishnan, D. Premec.

Date: May 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6602

For extending the lifetime of a mobility session, the Proxy MobileIPv6 specification requires the mobile access gateway to send a ProxyBinding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group-specific scope, this results in a significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group-specific scope with the use of a group identifier.

RFC 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation

Authors: J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan.

Date: May 2012

Formats: txt html json

Updates: RFC 3633

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6603

This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when usingDHCPv6-based prefix delegation. The new mechanism updates RFC 3633.

RFC 6604 xNAME RCODE and Status Bits Clarification

Authors: D. Eastlake 3rd.

Date: April 2012

Formats: txt json html

Updates: RFC 1035, RFC 2308, RFC 2672

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6604

The Domain Name System (DNS) has long provided means, such as theCNAME (Canonical Name), whereby a DNS query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how theRCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles.

RFC 6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC

Authors: P. Hoffman, W.C.A. Wijngaards.

Date: April 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6605

This document describes how to specify Elliptic Curve DigitalSignature Algorithm (DSA) keys and signatures in DNS Security(DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures.

RFC 6606 Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing

Authors: E. Kim, D. Kaspar, C. Gomez, C. Bormann.

Date: May 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6606

IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.
This document provides the problem statement and design space for6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETFROLL WG.

RFC 6607 Virtual Subnet Selection Options for DHCPv4 and DHCPv6

Authors: K. Kinnear, R. Johnson, M. Stapp.

Date: April 2012

Formats: txt html json

Updates: RFC 3046

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6607

This memo defines a DHCPv4 Virtual Subnet Selection (VSS) option, aDHCPv6 VSS option, and the DHCPv4 VSS and VSS-Control sub-options carried in the DHCPv4 Relay Agent Information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place.
For the DHCPv4 option and Relay Agent Information sub-options, this memo documents and extends existing usage as per RFC 3942. This memo updates RFC 3046 regarding details relating to the copying of sub- options (see Section 8).

RFC 6608 Subcodes for BGP Finite State Machine Error

Authors: J. Dong, M. Chen, A. Suryanarayana.

Date: May 2012

Formats: txt json html

Updates: RFC 4271

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6608

This document defines several subcodes for the BGP Finite StateMachine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. This document updates RFC 4271.

RFC 6609 Sieve Email Filtering: Include Extension

Authors: C. Daboo, A. Stone.

Date: May 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6609

The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts.

RFC 6610 DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6)

Authors: H. Jang, A. Yegin, K. Chowdhury, J. Choi, T. Lemon.

Date: May 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6610

This document defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined that allow a mobile node to request the home agent IP address, Fully Qualified Domain Name (FQDN), or home network prefix and obtain it via the DHCP response.

RFC 6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario

Authors: K. Chowdhury, Ed., A. Yegin.

Date: May 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6611

Mobile IPv6 bootstrapping can be categorized into two primary scenarios: the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario.

RFC 6612 Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues

Authors: G. Giaretta, Ed..

Date: May 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6612

The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described.

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 6615 Definitions of Managed Objects for IP Flow Information Export

Authors: T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz.

Date: June 2012

Formats: txt json html

Obsoletes: RFC 5815

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6615

This document defines managed objects for IP Flow Information eXport(IPFIX). These objects provide information for monitoring IPFIXExporters and IPFIX Collectors, including basic configuration information.

RFC 6616 A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID

Authors: E. Lear, H. Tschofenig, H. Mauldin, S. Josefsson.

Date: May 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6616

OpenID has found its usage on the Internet for Web Single Sign-On.Simple Authentication and Security Layer (SASL) and the GenericSecurity Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API.

RFC 6617 Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE)

Authors: D. Harkins.

Date: June 2012

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6617

This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE). It is resistant to dictionary attack and retains security even when used with weak pre-shared keys.

RFC 6618 Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent

Authors: J. Korhonen, Ed., B. Patil, H. Tschofenig, D. Kroeselberg.

Date: May 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6618

Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent(HA) is secured using IPsec. The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol(IKE) version 1 or 2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the MobileIPv6 protocol component and the IKE/IPsec module of the IP stack.This document proposes an alternate security framework for MobileIPv6 and Dual-Stack Mobile IPv6, which relies on Transport LayerSecurity for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA.

RFC 6619 Scalable Operation of Address Translators with Per-Interface Bindings

Authors: J. Arkko, L. Eggert, M. Townsley.

Date: June 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6619

This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space.

RFC 6620 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses

Authors: E. Nordmark, M. Bagnulo, E. Levy-Abegnoli.

Date: May 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6620

This memo describes First-Come, First-Served Source AddressValidation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing.

RFC 6621 Simplified Multicast Forwarding

Authors: J. Macker, Ed..

Date: May 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6621

This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade- off. It defines techniques for multicast duplicate packet detection(DPD), to be applied in the forwarding process, for both IPv4 andIPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding.Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicastMANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document.

RFC 6622 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)

Authors: U. Herberg, T. Clausen.

Date: May 2012

Formats: txt html json

Obsoleted by: RFC 7182

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6622

This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively.

RFC 6623 IANA Registry for MEDIACTRL Interactive Voice Response Control Package

Authors: E. Burger.

Date: May 2012

Formats: txt html json

Updates: RFC 6231

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6623

This document creates an IANA registry for the response codes for theMEDIACTRL Interactive Voice Response Control Package, as described inRFC 6231.

RFC 6624 Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling

Authors: K. Kompella, B. Kothari, R. Cherukuri.

Date: May 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6624

Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular.Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IPVPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services.

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 6626 Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4)

Authors: G. Tsirtsis, V. Park, V. Narayanan, K. Leung.

Date: May 2012

Formats: txt html json

Updates: RFC 5177

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6626

The base Network Mobility for Mobile IPv4 (NEMOv4) specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism forNEMOv4.

RFC 6627 Overview of Pre-Congestion Notification Encoding

Authors: G. Karagiannis, K. Chan, T. Moncaster, M. Menth, P. Eardley, B. Briscoe.

Date: July 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6627

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain.On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre-congestion.
The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution.

RFC 6628 Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2

Authors: S. Shin, K. Kobara.

Date: June 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6628

This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks). The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2).

RFC 6629 Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6)

Authors: J. Abley, M. Bagnulo, A. Garcia-Martinez.

Date: June 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6629

This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6.

RFC 6630 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)

Authors: Z. Cao, H. Deng, Q. Wu, G. Zorn, Ed..

Date: June 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6630

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.
The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator.
Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or moreCandidate Attachment Points (CAPs) prior to handover. AAK uses theAAA infrastructure for key transport.
This document specifies the extensions necessary to enable AAK support in ERP.

RFC 6631 Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)

Authors: D. Kuegler, Y. Sheffer.

Date: June 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6631

The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password- authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration.

RFC 6632 An Overview of the IETF Network Management Standards

Authors: M. Ersue, Ed., B. Claise.

Date: June 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6632

This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETFStandards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other StandardDevelopment Organizations or bodies planning to use IETF management technologies and data models. This document does not coverOperations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP)OAM, and pseudowire as well as the corresponding management models.

RFC 6633 Deprecation of ICMP Source Quench Messages

Authors: F. Gont.

Date: May 2012

Formats: txt html json

Updates: RFC 0792, RFC 1122, RFC 1812

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6633

This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812.

RFC 6635 RFC Editor Model (Version 2)

Authors: O. Kolkman, Ed., J. Halpern, Ed., IAB.

Date: June 2012

Formats: txt json html

Obsoletes: RFC 5620

Obsoleted by: RFC 8728

Status: INFORMATIONAL

DOI: 10.17487/RFC 6635

The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFCSeries Editor, the RFC Production Center, and the RFC Publisher.Internet Architecture Board (IAB) oversight via the RFC SeriesOversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and theRSOC. This document reflects the experience gained with "RFC EditorModel (Version 1)", documented in RFC 5620, and obsoletes that document.

RFC 6636 Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks

Authors: H. Asaeda, H. Liu, Q. Wu.

Date: May 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6636

The Internet Group Management Protocol (IGMP) and Multicast ListenerDiscovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other.This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values.

RFC 6637 Elliptic Curve Cryptography (ECC) in OpenPGP

Authors: A. Jivsov.

Date: June 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6637

This document defines an Elliptic Curve Cryptography extension to theOpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves.

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 6639 Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview

Authors: D. King, Ed., M. Venkatesan, Ed..

Date: June 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6639

A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects ofMultiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.
The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks.
This document describes the MIB-based architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management, and identifies areas where additional MIB modules are required.

RFC 6640 IETF Meeting Attendees' Frequently Asked (Travel) Questions

Authors: W. George.

Date: June 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6640

This document attempts to provide a list of the frequently asked questions (FAQs) posed by IETF meeting attendees regarding travel logistics and local information. It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in theIETF wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. It is not meant as a list of required information that the host or Secretariat needs to provide; it merely serves as a guideline.

RFC 6641 Using DNS SRV to Specify a Global File Namespace with NFS Version 4

Authors: C. Everhart, W. Adamson, J. Zhang.

Date: June 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6641

The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace. The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization-wide file namespaces together to allow construction of a global, uniform NFS file namespace.

RFC 6642 RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report

Authors: Q. Wu, Ed., F. Xia, R. Even.

Date: June 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6642

In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated SessionDescription Protocol (SDP) signaling is also defined.

RFC 6643 Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules

Authors: J. Schoenwaelder.

Date: July 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6643

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol(NETCONF), NETCONF remote procedure calls, and NETCONF notifications.The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revisingMIB modules for use with the Simple Network Management Protocol(SNMP). This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF.

RFC 6644 Rebind Capability in DHCPv6 Reconfigure Messages

Authors: D. Evans, R. Droms, S. Jiang.

Date: July 2012

Formats: txt html json

Updates: RFC 3315

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6644

This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message.

RFC 6645 IP Flow Information Accounting and Export Benchmarking Methodology

Authors: J. Novak.

Date: July 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6645

This document provides a methodology and framework for quantifying the performance impact of the monitoring of IP flows on a network device and the export of this information to a Collector. It identifies the rate at which the IP flows are created, expired, and successfully exported as a new performance metric in combination with traditional throughput. The metric is only applicable to the devices compliant with RFC 5470, "Architecture for IP Flow InformationExport". The methodology quantifies the impact of the IP flow monitoring process on the network equipment.

RFC 6646 DECoupled Application Data Enroute (DECADE) Problem Statement

Authors: H. Song, N. Zong, Y. Yang, R. Alimi.

Date: July 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6646

Peer-to-peer (P2P) applications have become widely used on theInternet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they can be complex (e.g., P2P caches need to explicitly support individual P2P application protocols), and do not allow users to manage resource usage policies for content in the cache. This document discusses the introduction of in-network storage for P2P applications and shows the need for a standard protocol for accessing this storage.

RFC 6647 Email Greylisting: An Applicability Statement for SMTP

Authors: M. Kucherawy, D. Crocker.

Date: June 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6647

This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism.
Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems.

RFC 6648 Deprecating the "X-" Prefix and Similar Constructs in Application Protocols

Authors: P. Saint-Andre, D. Crocker, M. Nottingham.

Date: June 2012

Formats: txt html json

Also: BCP 0178

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6648

Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual(as opposed to numerical) names in application protocols.

RFC 6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos

Authors: L. Hornquist Astrand, T. Yu.

Date: July 2012

Formats: txt html json

Obsoletes: RFC 1510

Updates: RFC 1964, RFC 4120, RFC 4121, RFC 4757

Also: BCP 0179

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6649

The Kerberos 5 network authentication protocol, originally specified in RFC 1510, can use the Data Encryption Standard (DES) for encryption. Almost 30 years after first publishing DES, the NationalInstitute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure. By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average.DES is long past its sell-by date. Accordingly, this document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms inKerberos. Because RFC 1510 (obsoleted by RFC 4120) supports onlyDES, this document recommends the reclassification of RFC 1510 asHistoric.

RFC 6650 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)

Authors: J. Falk, M. Kucherawy, Ed..

Date: June 2012

Formats: txt html json

Updates: RFC 5965

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6650

RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed.

RFC 6651 Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting

Authors: M. Kucherawy.

Date: June 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6651

This document presents extensions to the DomainKeys Identified Mail(DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion.

RFC 6652 Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format

Authors: S. Kitterman.

Date: June 2012

Formats: txt json html

Updates: RFC 4408

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6652

This memo presents extensions to the Abuse Reporting Format (ARF) andSender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion.
This memo updates RFC 4408 by providing an IANA registry for SPF modifiers.

RFC 6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks

Authors: B. Sarikaya, F. Xia, T. Lemon.

Date: July 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6653

As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 PrefixDelegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to aDHCPv6 server. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP. We also describe prefix management using Authentication, Authorization, and Accounting(AAA) servers.

RFC 6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)

Authors: T. Tsou, C. Zhou, T. Taylor, Q. Chen.

Date: July 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6654

This document proposes an alternative IPv6 Rapid Deployment on IPv4Infrastructures (6rd) deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator'sIPv4 network edge rather than from customer equipment, and hence is termed "Gateway-initiated 6rd" (GI 6rd). The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment.

RFC 6655 AES-CCM Cipher Suites for Transport Layer Security (TLS)

Authors: D. McGrew, D. Bailey.

Date: July 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6655

This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message AuthenticationCode (CBC-MAC) Mode (CCM) of operation within Transport LayerSecurity (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments.

RFC 6656 Description of Cisco Systems' Subnet Allocation Option for DHCPv4

Authors: R. Johnson, K. Kinnear, M. Stapp.

Date: July 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6656

This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the CiscoSystems' Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range128-223 should be documented and that the working group will try to officially assign those numbers to those options.

RFC 6657 Update to MIME regarding "charset" Parameter Handling in Textual Media Types

Authors: A. Melnikov, J. Reschke.

Date: July 2012

Formats: txt json html

Updates: RFC 2046

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6657

This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers.

RFC 6658 Packet Pseudowire Encapsulation over an MPLS PSN

Authors: S. Bryant, Ed., L. Martini, G. Swallow, A. Malis.

Date: July 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6658

This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer3 protocols between the pair of client LSRs.

RFC 6659 Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method

Authors: A. Begen.

Date: July 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6659

The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicastRTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios.

RFC 6660 Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)

Authors: B. Briscoe, T. Moncaster, M. Menth.

Date: July 2012

Formats: txt html json

Obsoletes: RFC 5696

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6660

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain.The overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion.
This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix. The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked(NM), threshold-marked (ThM), and excess-traffic-marked (ETM).Hence, it is called the 3-in-1 PCN encoding. This document obsoletesRFC 5696.

RFC 6661 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation

Authors: A. Charny, F. Huang, G. Karagiannis, M. Menth, T. Taylor, Ed..

Date: July 2012

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6661

Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using three PCN marking states: not- marked, threshold-marked, and excess-traffic-marked. This behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior.

RFC 6662 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation

Authors: A. Charny, J. Zhang, G. Karagiannis, M. Menth, T. Taylor, Ed..

Date: July 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6662

Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using two PCN marking states: not- marked and excess-traffic-marked. This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior.

RFC 6663 Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain

Authors: G. Karagiannis, T. Taylor, K. Chan, M. Menth, P. Eardley.

Date: July 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6663

Pre-Congestion Notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN- domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the Decision Point; (2) the Decision Point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. TheDecision Point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors,Controlled Load (CL) and Single Marking (SM).

RFC 6664 S/MIME Capabilities for Public Key Definitions

Authors: J. Schaad.

Date: July 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6664

This document defines a set of Secure/Multipurpose Internet MailExtensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses."Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used.

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 6666 A Discard Prefix for IPv6

Authors: N. Hilliard, D. Freedman.

Date: August 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6666

Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates the "IPv6 SpecialPurpose Address Registry" by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitatingIPv6 remote triggered black hole filtering and routing.

RFC 6667 LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements

Authors: K. Raza, S. Boutros, C. Pignataro.

Date: July 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6667

The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when requesting, withdrawing, or releasing all label bindings for a given FEC Element type is desired. However, a TypedWildcard FEC Element must be individually defined for each FECElement type. This specification defines the Typed Wildcard FECElements for the Pseudowire Identifier (PWid) (0x80) and GeneralizedPWid (0x81) FEC Element types.

RFC 6668 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol

Authors: D. Bider, M. Baushke.

Date: July 2012

Formats: txt html json

Updates: RFC 4253

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6668

This memo defines algorithm names and parameters for use in some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol. It also updates RFC4253 by specifying a new RECOMMENDED data integrity algorithm.

RFC 6669 An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks

Authors: N. Sprecher, L. Fang.

Date: July 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6669

This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels.This overview includes a brief recap of the MPLS Transport Profile(MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document.

RFC 6670 The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)

Authors: N. Sprecher, KY. Hong.

Date: July 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6670

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work onMPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.
During the process of development of the profile, additions to theMPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment.
One major set of additions provides enhanced support for Operations,Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization.

RFC 6671 Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)

Authors: M. Betts.

Date: November 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6671

This document assigns a Generic Associated Channel (G-ACh) Type for carrying ITU-T MPLS Transport Profile Operations, Administration, andManagement (MPLS-TP OAM) messages in the MPLS Generic AssociatedChannel.

RFC 6672 DNAME Redirection in the DNS

Authors: S. Rose, W. Wijngaards.

Date: June 2012

Formats: txt json html

Obsoletes: RFC 2672

Updates: RFC 3363

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6672

The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363).

RFC 6673 Round-Trip Packet Loss Metrics

Authors: A. Morton.

Date: August 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6673

Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active MeasurementProtocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.
This memo adds round-trip loss to the set of IP Performance Metrics(IPPM).

RFC 6674 Gateway-Initiated Dual-Stack Lite Deployment

Authors: F. Brockners, S. Gundavelli, S. Speicher, D. Ward.

Date: July 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6674

Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual-Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embeddedContext Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire.

RFC 6675 A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP

Authors: E. Blanton, M. Allman, L. Wang, I. Jarvinen, M. Kojo, Y. Nishida.

Date: August 2012

Formats: txt html json

Obsoletes: RFC 3517

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6675

This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it.

RFC 6676 Multicast Addresses for Documentation

Authors: S. Venaas, R. Parekh, G. Van de Velde, T. Chown, M. Eubanks.

Date: August 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6676

This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use.Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes.

RFC 6677 Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods

Authors: S. Hartman, Ed., T. Clancy, K. Hoeper.

Date: July 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6677

This document defines how to implement channel bindings forExtensible Authentication Protocol (EAP) methods to address the"lying Network Access Service (NAS)" problem as well as the "lying provider" problem.

RFC 6678 Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method

Authors: K. Hoeper, S. Hanna, H. Zhou, J. Salowey, Ed..

Date: July 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6678

This memo defines the requirements for a tunnel-based ExtensibleAuthentication Protocol (EAP) Method. This tunnel method will useTransport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes.

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 6680 Generic Security Service Application Programming Interface (GSS-API) Naming Extensions

Authors: N. Williams, L. Johansson, S. Hartman, S. Josefsson.

Date: August 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6680

The Generic Security Service Application Programming Interface(GSS-API) provides a simple naming architecture that supports name- based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer betweenGSS-API peers.

RFC 6681 Raptor Forward Error Correction (FEC) Schemes for FECFRAME

Authors: M. Watson, T. Stockhammer, M. Luby.

Date: August 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6681

This document describes Fully-Specified Forward Error Correction(FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FECFramework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. TheRaptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FECSchemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport(e.g., UDP) or using RTP.

RFC 6682 RTP Payload Format for Raptor Forward Error Correction (FEC)

Authors: M. Watson, T. Stockhammer, M. Luby.

Date: August 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6682

This document specifies an RTP payload format for the Forward ErrorCorrection (FEC) repair data produced by the Raptor FEC Schemes.Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP.This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows.

RFC 6683 Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection

Authors: A. Begen, T. Stockhammer.

Date: August 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6683

Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward ErrorCorrection (AL-FEC) protocol to protect the streaming media transported using RTP. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents.

RFC 6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)

Authors: B. Trammell.

Date: July 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6684

This document provides guidelines for extensions to the IncidentObject Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template forInternet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions.

RFC 6685 Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry

Authors: B. Trammell.

Date: July 2012

Formats: txt html json

Obsoleted by: RFC 7970

Updates: RFC 5070

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6685

This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require ExpertReview for extensions to Incident Object Description Exchange Format(IODEF).

RFC 6686 Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments

Authors: M. Kucherawy.

Date: July 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6686

In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery.
The IESG required all of these documents (RFC 4405, RFC 4406, RFC4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward.
After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings.

RFC 6687 Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)

Authors: J. Tripathi, Ed., J. de Oliveira, Ed., JP. Vasseur, Ed..

Date: October 2012

Formats: txt json pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6687

This document presents a performance evaluation of the RoutingProtocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network.Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios.Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version.

RFC 6688 Parallel NFS (pNFS) Block Disk Protection

Authors: D. Black, Ed., J. Glasgow, S. Faibish.

Date: July 2012

Formats: txt html json

Updates: RFC 5663

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6688

Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server. This can increase both performance and parallelism, but it requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server.

RFC 6689 Usage of the RSVP ASSOCIATION Object

Authors: L. Berger.

Date: July 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6689

The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-controlled label switched paths(LSPs). In this context, the object is used to associate recoveryLSPs with the LSP they are protecting. This document reviews how the association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature.

RFC 6690 Constrained RESTful Environments (CoRE) Link Format

Authors: Z. Shelby.

Date: August 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6690

This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTPLink Header field defined in RFC 5988, the Constrained RESTfulEnvironments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to theRepresentational State Transfer (REST) architecture. A well-knownURI is defined as a default entry point for requesting the links hosted by a server.

RFC 6691 TCP Options and Maximum Segment Size (MSS)

Authors: D. Borman.

Date: July 2012

Formats: txt html json

Obsoleted by: RFC 9293

Updates: RFC 0879, RFC 2385

Status: INFORMATIONAL

DOI: 10.17487/RFC 6691

This memo discusses what value to use with the TCP Maximum SegmentSize (MSS) option, and updates RFC 879 and RFC 2385.

RFC 6692 Source Ports in Abuse Reporting Format (ARF) Reports

Authors: R. Clayton, M. Kucherawy.

Date: July 2012

Formats: txt json html

Updates: RFC 6591

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6692

This document defines an additional header field for use in AbuseReporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.
This document updates RFC 6591.

RFC 6693 Probabilistic Routing Protocol for Intermittently Connected Networks

Authors: A. Lindgren, A. Doria, E. Davies, S. Grasic.

Date: August 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6693

This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.
This document defines PRoPHET, a Probabilistic Routing Protocol usingHistory of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the best-case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between the source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as delay and disruption tolerant). The document presents an architectural overview followed by the protocol specification.

RFC 6694 The "about" URI Scheme

Authors: S. Moonesamy, Ed..

Date: August 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6694

This document describes the "about" URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on.

RFC 6695 Methods to Convey Forward Error Correction (FEC) Framework Configuration Information

Authors: R. Asati.

Date: August 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6695

The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for theFEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time StreamingProtocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).
This document doesn't define any new signaling protocol.

RFC 6696 EAP Extensions for the EAP Re-authentication Protocol (ERP)

Authors: Z. Cao, B. He, Y. Shi, Q. Wu, Ed., G. Zorn, Ed..

Date: July 2012

Formats: txt json html

Obsoletes: RFC 5296

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6696

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting.
This memo obsoletes RFC 5296.

RFC 6697 Handover Keying (HOKEY) Architecture Design

Authors: G. Zorn, Ed., Q. Wu, T. Taylor, Y. Nir, K. Hoeper, S. Decugis.

Date: July 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6697

The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748.
This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY WorkingGroup.

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 6701 Sanctions Available for Application to Violators of IETF IPR Policy

Authors: A. Farrel, P. Resnick.

Date: August 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6701

The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to IntellectualProperty Rights (IPR) about which they might reasonably be aware.
The IETF takes conformance to these IPR policies very seriously.However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied.
This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents.

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 6703 Reporting IP Network Performance Metrics: Different Points of View

Authors: A. Morton, G. Ramachandran, G. Maguluri.

Date: August 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6703

Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations(e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs.

RFC 6704 Forcerenew Nonce Authentication

Authors: D. Miles, W. Dec, J. Bristow, R. Maglione.

Date: August 2012

Formats: txt html json

Updates: RFC 3203

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6704

Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into aRenew state on a trigger from the DHCP server. In the ForcerenewNonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of aFORCERENEW message. This document updates RFC 3203.

RFC 6705 Localized Routing for Proxy Mobile IPv6

Authors: S. Krishnan, R. Koodli, P. Loureiro, Q. Wu, A. Dutta.

Date: September 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6705

Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) andLocal Routing Acknowledgment (LRA), that are used to realize this mechanism.

RFC 6706 Asymmetric Extended Route Optimization (AERO)

Authors: F. Templin, Ed..

Date: August 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6706

Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios.This document therefore introduces an Asymmetric Extended RouteOptimization (AERO) capability that addresses the issues.

RFC 6707 Content Distribution Network Interconnection (CDNI) Problem Statement

Authors: B. Niven-Jenkins, F. Le Faucheur, N. Bitar.

Date: September 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6707

Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that EndUser's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.
The goal of this document is to outline the problem area of CDNInterconnection for the IETF CDNI (CDN Interconnection) working group.

RFC 6708 Application-Layer Traffic Optimization (ALTO) Requirements

Authors: S. Kiesel, Ed., S. Previdi, M. Stiemerling, R. Woundy, Y. Yang.

Date: September 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6708

Many Internet applications are used to access resources, such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource.This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance orQuality of Experience in the application while reducing the utilization of the underlying network infrastructure.
This document enumerates requirements for specifying, assessing, or comparing protocols and implementations.

RFC 6709 Design Considerations for Protocol Extensions

Authors: B. Carpenter, B. Aboba, Ed., S. Cheshire.

Date: September 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6709

This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols.

RFC 6710 Simple Mail Transfer Protocol Extension for Message Transfer Priorities

Authors: A. Melnikov, K. Carlberg.

Date: August 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6710

This memo defines an extension to the SMTP (Simple Mail TransferProtocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing.

RFC 6711 An IANA Registry for Level of Assurance (LoA) Profiles

Authors: L. Johansson.

Date: August 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6711

This document establishes an IANA registry for Level of Assurance(LoA) Profiles. The registry is intended to be used as an aid to discovering such LoA definitions in protocols that use an LoA concept, including Security Assertion Markup Language (SAML) 2.0 andOpenID Connect.

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 6713 The 'application/zlib' and 'application/gzip' Media Types

Authors: J. Levine.

Date: August 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6713

This document defines the 'application/gzip' and 'application/zlib' media types for compressed data using the gzip and zlib compression formats.

RFC 6714 Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)

Authors: C. Holmberg, S. Blau, E. Burger.

Date: August 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6714

This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA).Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol(SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension.

RFC 6715 vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group

Authors: D. Cauchie, B. Leiba, K. Li.

Date: August 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6715

This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance(OMA) Converged Address Book group, in order to synchronize, usingOMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification.

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 6717 kx509 Kerberized Certificate Issuance Protocol in Use in 2012

Authors: H. Hotz, R. Allbery.

Date: August 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6717

This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less.
While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation.

RFC 6718 Pseudowire Redundancy

Authors: P. Muley, M. Aissaoui, M. Bocci.

Date: August 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6718

This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy.A set of redundant PWs is configured between provider edge (PE) nodes in single-segment PW applications or between terminating PE (T-PE) nodes in multi-segment 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 PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundant set.

RFC 6719 The Minimum Rank with Hysteresis Objective Function

Authors: O. Gnawali, P. Levis.

Date: September 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6719

The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function(MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPLDestination Information Object (DIO) messages advertise.

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 6721 The Atom "deleted-entry" Element

Authors: J. Snell.

Date: September 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6721

This specification adds mechanisms to the Atom Syndication Format that publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed.

RFC 6722 Publishing the "Tao of the IETF" as a Web Page

Authors: P. Hoffman, Ed..

Date: August 2012

Formats: txt json html

Obsoletes: RFC 4677

Status: INFORMATIONAL

DOI: 10.17487/RFC 6722

This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, is instead being published as a web page. It also contains the procedure for publishing and editing that web page.

RFC 6723 Update of the Pseudowire Control-Word Negotiation Mechanism

Authors: L. Jin, Ed., R. Key, Ed., S. Delord, T. Nadeau, S. Boutros.

Date: September 2012

Formats: txt json html

Obsoleted by: RFC 8077

Updates: RFC 4447, RFC 6073

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6723

The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED. This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires.

RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6)

Authors: D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown.

Date: September 2012

Formats: txt html json

Obsoletes: RFC 3484

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6724

This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.
Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484.

RFC 6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates

Authors: S. Rose.

Date: August 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6725

The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures over DNS data.The algorithms specified for use with DNSSEC are reflected in anIANA-maintained registry. This document presents a set of changes for some entries of the registry.

RFC 6726 FLUTE - File Delivery over Unidirectional Transport

Authors: T. Paila, R. Walsh, M. Luby, V. Roca, R. Lehtonen.

Date: November 2012

Formats: txt json html

Obsoletes: RFC 3926

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6726

This document defines File Delivery over Unidirectional Transport(FLUTE), a protocol for the unidirectional delivery of files over theInternet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution.This document obsoletes RFC 3926.

RFC 6727 Definitions of Managed Objects for Packet Sampling

Authors: T. Dietz, Ed., B. Claise, J. Quittek.

Date: October 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6727

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 extensions to the IPFIX-SELECTOR-MIB module. For IP Flow Information eXport (IPFIX) implementations that use Packet Sampling (PSAMP) techniques, this memo defines the PSAMP-MIB module containing managed objects for providing information on applied packet selection functions and their parameters.

RFC 6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols

Authors: G. Muenz, B. Claise, P. Aitken.

Date: October 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6728

This document specifies a data model for the IP Flow InformationExport (IPFIX) and Packet Sampling (PSAMP) protocols. It is for configuring and monitoring Selection Processes, Caches, ExportingProcesses, and Collecting Processes of IPFIX- and PSAMP-compliantMonitoring Devices using the Network Configuration Protocol(NETCONF). The data model is defined using UML (Unified ModelingLanguage) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML).

RFC 6729 Indicating Email Handling States in Trace Fields

Authors: D. Crocker, M. Kucherawy.

Date: September 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6729

This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues.

RFC 6730 Requirements for IETF Nominations Committee Tools

Authors: S. Krishnan, J. Halpern.

Date: September 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6730

This document defines the requirements for a set of tools for use by the IETF Nominations Committee.

RFC 6731 Improved Recursive DNS Server Selection for Multi-Interfaced Nodes

Authors: T. Savolainen, J. Kato, T. Lemon.

Date: December 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6731

A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers might have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use. This document describesDHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions.

RFC 6732 6to4 Provider Managed Tunnels

Authors: V. Kuarsingh, Ed., Y. Lee, O. Vautrin.

Date: September 2012

Formats: txt json html

Obsoleted by: RFC 7526

Status: HISTORIC

DOI: 10.17487/RFC 6732

6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor.

RFC 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 6734 Diameter Attribute-Value Pairs for Cryptographic Key Transport

Authors: G. Zorn, Q. Wu, V. Cakulev.

Date: October 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6734

Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery.

RFC 6735 Diameter Priority Attribute-Value Pairs

Authors: K. Carlberg, Ed., T. Taylor.

Date: October 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6735

This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and theAuthentication, Authorization, and Accounting (AAA) framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer.

RFC 6736 Diameter Network Address and Port Translation Control Application

Authors: F. Brockners, S. Bhandari, V. Singh, V. Fajardo.

Date: October 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6736

This document describes the framework, messages, and procedures for the Diameter Network address and port translation ControlApplication. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and PortTranslators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a NetworkAddress Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator andNetwork Address and Port Translator device. This includes, for example, the control of the total number of Network AddressTranslator bindings allowed or the allocation of a specific NetworkAddress Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes.

RFC 6737 The Diameter Capabilities Update Application

Authors: K. Jiao, G. Zorn.

Date: October 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6737

This document defines a new Diameter application and associatedCommand Codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state.

RFC 6738 Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers

Authors: V. Cakulev, A. Lior, S. Mizikovsky.

Date: October 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6738

The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec SecurityAssociations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the ExtensibleAuthentication Protocol (EAP), certificates, and Shared Key (SK).
Diameter interworking for Mobile IPv6 between the Home Agent (HA), as a Diameter client, and the Diameter server has been specified.However, that specification focused on the usage of EAP and did not include support for SK-based authentication available with IKEv2.This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK.

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 6740 Identifier-Locator Network Protocol (ILNP) Architectural Description

Authors: RJ Atkinson, SN Bhatti.

Date: November 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6740

This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group.

RFC 6741 Identifier-Locator Network Protocol (ILNP) Engineering Considerations

Authors: RJ Atkinson, SN Bhatti.

Date: November 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6741

This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol(ILNP), which is an experimental, evolutionary enhancement to IP.This document is a product of the IRTF Routing Research Group.

RFC 6742 DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)

Authors: RJ Atkinson, SN Bhatti, S. Rose.

Date: November 2012

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6742

This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group.

RFC 6743 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)

Authors: RJ Atkinson, SN Bhatti.

Date: November 2012

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6743

This note specifies an experimental ICMPv6 message type used with theIdentifier-Locator Network Protocol (ILNP). The Identifier-LocatorNetwork Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTFRouting Research Group.

RFC 6744 IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)

Authors: RJ Atkinson, SN Bhatti.

Date: November 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6744

The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations.This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of theIRTF Routing Research Group.

RFC 6745 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)

Authors: RJ Atkinson, SN Bhatti.

Date: November 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6745

This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). ILNP is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTFRouting Research Group.

RFC 6746 IPv4 Options for the Identifier-Locator Network Protocol (ILNP)

Authors: RJ Atkinson, SN Bhatti.

Date: November 2012

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6746

This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group.

RFC 6747 Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)

Authors: RJ Atkinson, SN Bhatti.

Date: November 2012

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6747

This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4).ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group.

RFC 6748 Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)

Authors: RJ Atkinson, SN Bhatti.

Date: November 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6748

This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for theIdentifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management ofILNP-based systems.

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 6751 Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)

Authors: R. Despres, Ed., B. Carpenter, D. Wing, S. Jiang.

Date: October 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6751

In customer sites having IPv4-only Customer Premises Equipment (CPE),Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs(an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used.

RFC 6752 Issues with Private IP Addressing in the Internet

Authors: A. Kirkham.

Date: September 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6752

The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network. The discussion focuses on link addresses and, to a small extent, loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues.

RFC 6753 A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)

Authors: J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson.

Date: October 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6753

This document describes how to use the Hypertext Transfer Protocol(HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format LocationObject (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-EnabledLocation Delivery (HELD) protocol to request the location of theTarget.

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 6755 An IETF URN Sub-Namespace for OAuth

Authors: B. Campbell, H. Tschofenig.

Date: October 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6755

This document establishes an IETF URN Sub-namespace for use withOAuth-related specifications.

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 6758 Tunneling of SMTP Message Transfer Priorities

Authors: A. Melnikov, K. Carlberg.

Date: October 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6758

This memo defines a mechanism for tunneling of SMTP (Simple MailTransfer Protocol) Message Transfer Priority values through MTAs(Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension.

RFC 6759 Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)

Authors: B. Claise, P. Aitken, N. Ben-Dvora.

Date: November 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6759

This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information.

RFC 6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)

Authors: S. Cheshire, M. Krochmal.

Date: February 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6760

One of the goals of the authors of Multicast DNS (mDNS) and DNS-BasedService Discovery (DNS-SD) was to retire AppleTalk and the AppleTalkName Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.

RFC 6761 Special-Use Domain Names

Authors: S. Cheshire, M. Krochmal.

Date: February 2013

Formats: txt json html

Updates: RFC 1918, RFC 2606

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6761

This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.

RFC 6762 Multicast DNS

Authors: S. Cheshire, M. Krochmal.

Date: February 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6762

As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.
Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventionalUnicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.
The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.

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 6764 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)

Authors: C. Daboo.

Date: February 2013

Formats: txt json html

Updates: RFC 4791, RFC 6352

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6764

This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locateCalDAV (Calendaring Extensions to Web Distributed Authoring andVersioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.

RFC 6765 xDSL Multi-Pair Bonding (G.Bond) MIB

Authors: E. Beili, M. Morgenstern.

Date: February 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6765

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded DigitalSubscriber Line (xDSL) interfaces, as defined in ITU-TRecommendations G.998.1, G.998.2, and G.998.3. The textual conventions defining the bonding schemes are contained in a separateMIB module maintained by Internet Assigned Numbers Authority (IANA).The MIB modules specific to each bonding technology are defined inG9981-MIB, G9982-MIB, and G9983-MIB, respectively.

RFC 6766 xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB

Authors: E. Beili.

Date: February 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6766

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces usingTime-Division Inverse Multiplexing (TDIM), as defined in ITU-TRecommendation G.998.3.

RFC 6767 Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB

Authors: E. Beili, M. Morgenstern.

Date: February 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6767

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded DigitalSubscriber Line (xDSL) interfaces, as defined in ITU-T RecommendationG.998.2.

RFC 6768 ATM-Based xDSL Bonded Interfaces MIB

Authors: E. Beili.

Date: February 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6768

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1.

RFC 6769 Simple Virtual Aggregation (S-VA)

Authors: R. Raszuk, J. Heitz, A. Lo, L. Zhang, X. Xu.

Date: October 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6769

All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into theForwarding Information Base (FIB).
Some routers in an Autonomous System (AS) announce an aggregate (theVA prefix) in addition to the routes they already announce. This enables other routers not to install the routes covered by the VA prefix into the FIB as long as those routes have the same next-hop as the VA prefix.
The VA prefixes that are announced within an AS are not announced to any other AS. The described functionality is of very low operational complexity, as it proposes a confined BGP speaker solution without any dependency on network-wide configuration or requirement for any form of intra-domain tunneling.

RFC 6770 Use Cases for Content Delivery Network Interconnection

Authors: G. Bertrand, Ed., E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson.

Date: November 2012

Formats: txt json html

Obsoletes: RFC 3570

Status: INFORMATIONAL

DOI: 10.17487/RFC 6770

Content Delivery Networks (CDNs) are commonly used for improving theEnd User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC3570.

RFC 6771 Considerations for Having a Successful "Bar BOF" Side Meeting

Authors: L. Eggert, G. Camarillo.

Date: October 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6771

New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "barBOF" sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic.
During recent IETF meetings, many such "bar BOF" get-togethers have been organized and moderated in ways that made them increasingly indistinguishable from official IETF BOFs or sometimes even IETF working group meetings.
This document argues that this recent trend is not helpful in reaching the ultimate goal of many of these get-togethers, i.e., to efficiently discuss and develop ideas for new IETF work. It encourages the organizers to consider the benefits of holding them in much less formal settings and to also consider alternative means to develop their ideas. This document also recommends that the community abandon the term "bar BOF" and instead use other terms such as "side meeting", in order to stress the unofficial nature of these get-togethers.

RFC 6772 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information

Authors: H. Schulzrinne, Ed., H. Tschofenig, Ed., J. Cuellar, J. Polk, J. Morris, M. Thomson.

Date: January 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6772

This document defines an authorization policy language for controlling access to location information. It extends the CommonPolicy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.
Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains.

RFC 6773 DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal

Authors: T. Phelan, G. Fairhurst, C. Perkins.

Date: November 2012

Formats: txt html json

Updates: RFC 4340, RFC 5762

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6773

This document specifies an alternative encapsulation of the DatagramCongestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates theSession Description Protocol (SDP) information for DCCP defined inRFC 5762.

RFC 6774 Distribution of Diverse BGP Paths

Authors: R. Raszuk, Ed., R. Fernando, K. Patel, D. McPherson, K. Kumaki.

Date: November 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6774

The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.
The main objective of this document is to observe that by simply adding a new session between a route reflector and its client, theNth best path can be distributed. This document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path.
This proposal does not specify any changes to the BGP protocol definition. It does not require a software upgrade of provider edge(PE) routers acting as route reflector clients.

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 6776 Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block

Authors: A. Clark, Q. Wu.

Date: October 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6776

This document defines an RTP Control Protocol (RTCP) SourceDescription (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer.

RFC 6777 Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks

Authors: W. Sun, Ed., G. Zhang, Ed., J. Gao, G. Xie, R. Papneja.

Date: November 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6777

When setting up a Label Switched Path (LSP) in Generalized MPLS(GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner. Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable. The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross- connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and useLSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process.

RFC 6778 Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching

Authors: R. Sparks.

Date: October 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6778

The IETF makes heavy use of email lists to conduct its work.Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems.

RFC 6779 Definition of Managed Objects for the Neighborhood Discovery Protocol

Authors: U. Herberg, R. Cole, I. Chakeres.

Date: October 2012

Formats: txt json html

Obsoleted by: RFC 7939

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6779

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications aboutNHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery.

RFC 6780 RSVP ASSOCIATION Object Extensions

Authors: L. Berger, F. Le Faucheur, A. Narayanan.

Date: October 2012

Formats: txt json html

Updates: RFC 2205, RFC 3209, RFC 3473, RFC 4872

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6780

The RSVP ASSOCIATION object was defined in the context of GMPLS- controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting.This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also definesExtended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872.

RFC 6781 DNSSEC Operational Practices, Version 2

Authors: O. Kolkman, W. Mekking, R. Gieben.

Date: December 2012

Formats: txt json html

Obsoletes: RFC 4641

Status: INFORMATIONAL

DOI: 10.17487/RFC 6781

This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.
This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.

RFC 6782 Wireline Incremental IPv6

Authors: V. Kuarsingh, Ed., L. Howard.

Date: November 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6782

Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies.

RFC 6783 Mailing Lists and Non-ASCII Addresses

Authors: J. Levine, R. Gellens.

Date: November 2012

Formats: txt html json

Obsoletes: RFC 5983

Status: INFORMATIONAL

DOI: 10.17487/RFC 6783

This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice.

RFC 6784 Kerberos Options for DHCPv6

Authors: S. Sakane, M. Ishiyama.

Date: November 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6784

This document defines four new options for the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos.

RFC 6785 Support for Internet Message Access Protocol (IMAP) Events in Sieve

Authors: B. Leiba.

Date: November 2012

Formats: txt json html

Updates: RFC 5228

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6785

Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). Because this requires future Sieve extensions to specify their interactions with this one, this document updates the base Sieve specification, RFC 5228.

RFC 6786 Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs

Authors: A. Yegin, R. Cragie.

Date: November 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6786

This document specifies a mechanism for delivering the Protocol forCarrying Authentication for Network Access (PANA) Attribute-ValuePairs (AVPs) in encrypted form.

RFC 6787 Media Resource Control Protocol Version 2 (MRCPv2)

Authors: D. Burnett, S. Shanmugham.

Date: November 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6787

The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, theMRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server.

RFC 6788 The Line-Identification Option

Authors: S. Krishnan, A. Kavanagh, B. Varga, S. Ooghe, E. Nordmark.

Date: November 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6788

In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router.This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received RouterSolicitation messages. The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router.

RFC 6789 Congestion Exposure (ConEx) Concepts and Use Cases

Authors: B. Briscoe, Ed., R. Woundy, Ed., A. Cooper, Ed..

Date: December 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6789

This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today.

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 6791 Stateless Source Address Mapping for ICMPv6 Packets

Authors: X. Li, C. Bao, D. Wing, R. Vaithianathan, G. Huston.

Date: November 2012

Formats: txt json html

Updates: RFC 6145

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6791

A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases.

RFC 6792 Guidelines for Use of the RTP Monitoring Framework

Authors: Q. Wu, Ed., G. Hunt, P. Arden.

Date: November 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6792

This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics that attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks that cover their set of concerns. Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video.

RFC 6793 BGP Support for Four-Octet Autonomous System (AS) Number Space

Authors: Q. Vohra, E. Chen.

Date: December 2012

Formats: txt html json

Obsoletes: RFC 4893

Updates: RFC 4271

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6793

The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271.

RFC 6794 A Framework for Session Initiation Protocol (SIP) Session Policies

Authors: V. Hilt, G. Camarillo, J. Rosenberg.

Date: December 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6794

Proxy servers play a central role as an intermediary in the SessionInitiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies.

RFC 6795 A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies

Authors: V. Hilt, G. Camarillo.

Date: December 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6795

This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents (UAs) to subscribe to session policies for a SIP session and to receive notifications if these policies change.

RFC 6796 A User Agent Profile Data Set for Media Policy

Authors: V. Hilt, G. Camarillo, J. Rosenberg, D. Worley.

Date: December 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6796

This specification defines an XML document format to describe the media properties of Session Initiation Protocol (SIP) sessions.Examples for media properties are the codecs or media types used in the session. This document also defines an XML document format to describe policies that limit the media properties of SIP sessions.

RFC 6797 HTTP Strict Transport Security (HSTS)

Authors: J. Hodges, C. Jackson, A. Barth.

Date: November 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6797

This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to asHTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example.

RFC 6798 RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting

Authors: A. Clark, Q. Wu.

Date: November 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6798

This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications.

RFC 6801 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework

Authors: U. Kozat, A. Begen.

Date: November 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6801

This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the SessionDescription Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP.

RFC 6802 Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets

Authors: S. Baillargeon, C. Flinta, A. Johnsson.

Date: November 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6802

This memo describes an extension to the Two-Way Active MeasurementProtocol (TWAMP). Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions.

RFC 6803 Camellia Encryption for Kerberos 5

Authors: G. Hudson.

Date: November 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6803

This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC3961. The new types use the Camellia block cipher in CBC mode with ciphertext stealing and the CMAC algorithm for integrity protection.

RFC 6804 DISCOVER: Supporting Multicast DNS Queries

Authors: B. Manning.

Date: November 2012

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 6804

This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project. This project is no longer active and there are no current plans to restart it. TBDS was the first known use of multicast transport for DNS. A client multicasts a DNS query using theDISCOVER opcode and processes the multiple responses that may result.

RFC 6805 The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS

Authors: D. King, Ed., A. Farrel, Ed..

Date: November 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6805

Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path ComputationElement (PCE) architecture.
Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.
This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains.

RFC 6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals

Authors: S. Hartman, Ed., K. Raeburn, L. Zhu.

Date: November 2012

Formats: txt json html

Updates: RFC 4120

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6806

This memo documents a method for a Kerberos Key Distribution Center(KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realmTicket-Granting Ticket (TGT) to another realm on the referral path.The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120.

RFC 6807 Population Count Extensions to Protocol Independent Multicast (PIM)

Authors: D. Farinacci, G. Shepherd, S. Venaas, Y. Cai.

Date: December 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6807

This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the ProtocolIndependent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion.

RFC 6808 Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track

Authors: L. Ciavattone, R. Geib, A. Morton, M. Wieser.

Date: December 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6808

This memo provides the supporting test plan and results to advanceRFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. This memo also provides direct input for development of a revision of RFC 2679.

RFC 6809 Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)

Authors: C. Holmberg, I. Sedlacek, H. Kaplan.

Date: November 2012

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6809

This specification defines a new SIP header field, Feature-Caps. TheFeature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier(URI) of the Contact header field.
SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.
This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-CapabilityIndicator Trees", for registering feature-capability indicators.

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 6812 Cisco Service-Level Assurance Protocol

Authors: M. Chiba, A. Clemm, S. Medley, J. Salowey, S. Thombare, E. Yedavalli.

Date: January 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6812

Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is aPerformance Measurement protocol that has been widely deployed. The protocol is used to measure service-level parameters such as network latency, delay variation, and packet/frame loss. This document describes the Cisco SLA Protocol Measurement-Type UDP-Measurement, to enable vendor interoperability.

RFC 6813 The Network Endpoint Assessment (NEA) Asokan Attack Analysis

Authors: J. Salowey, S. Hanna.

Date: December 2012

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6813

The Network Endpoint Assessment (NEA) protocols are subject to a subtle forwarding attack that has become known as the NEA AsokanAttack. This document describes the attack and countermeasures that may be mounted.

RFC 6814 Formally Deprecating Some IPv4 Options

Authors: C. Pignataro, F. Gont.

Date: November 2012

Formats: txt html json

Obsoletes: RFC 1385, RFC 1393, RFC 1475, RFC 1770

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6814

A number of IPv4 options have become obsolete in practice, but have never been formally deprecated. This document deprecates such IPv4 options, thus cleaning up the corresponding IANA registry.Additionally, it obsoletes RFCs 1385, 1393, 1475, and 1770, and requests that the RFC Editor change their status to Historic.

RFC 6815 Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful

Authors: S. Bradner, K. Dubray, J. McQuaid, A. Morton.

Date: November 2012

Formats: txt html json

Updates: RFC 2544

Status: INFORMATIONAL

DOI: 10.17487/RFC 6815

The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity. Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods. This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope.

RFC 6816 Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME

Authors: V. Roca, M. Cunche, J. Lacan.

Date: December 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6816

This document describes a fully specified simple Forward ErrorCorrection (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases, and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum.

RFC 6817 Low Extra Delay Background Transport (LEDBAT)

Authors: S. Shalunov, G. Hazel, J. Iyengar, M. Kuehlewind.

Date: December 2012

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6817

Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows.

RFC 6818 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Authors: P. Yee.

Date: January 2013

Formats: txt html json

Updates: RFC 5280

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6818

This document updates RFC 5280, the "Internet X.509 Public KeyInfrastructure Certificate and Certificate Revocation List (CRL)Profile". This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations.

RFC 6819 OAuth 2.0 Threat Model and Security Considerations

Authors: T. Lodderstedt, Ed., M. McGloin, P. Hunt.

Date: January 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6819

This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol.

RFC 6820 Address Resolution Problems in Large Data Center Networks

Authors: T. Narten, M. Karir, I. Foo.

Date: January 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6820

This document examines address resolution issues related to the scaling of data centers with a very large number of hosts. The scope of this document is relatively narrow, focusing on address resolution(the Address Resolution Protocol (ARP) in IPv4 and Neighbor Discovery(ND) in IPv6) within a data center.

RFC 6821 Improving Peer Selection in Peer-to-peer Applications: Myths vs

Authors: Reality. E. Marocco, A. Fusco, I. Rimac, V. Gurbani.

Date: December 2012

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6821

Peer-to-peer (P2P) traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been the subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study or studies that have addressed facts pertaining to the myth. Using these studies, the authors hope to either confirm or refute each specific myth.
This document is a product of the IRTF P2PRG (Peer-to-Peer ResearchGroup).

RFC 6822 IS-IS Multi-Instance

Authors: S. Previdi, Ed., L. Ginsberg, M. Shand, A. Roy, D. Ward.

Date: December 2012

Formats: txt json html

Obsoleted by: RFC 8202

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6822

This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System toIntermediate System (IS-IS) routing protocol instances.
Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies.Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.

RFC 6823 Advertising Generic Information in IS-IS

Authors: L. Ginsberg, S. Previdi, M. Shand.

Date: December 2012

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6823

This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information.

RFC 6824 TCP Extensions for Multipath Operation with Multiple Addresses

Authors: A. Ford, C. Raiciu, M. Handley, O. Bonaventure.

Date: January 2013

Formats: txt html json

Obsoleted by: RFC 8684

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6824

TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.
Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.

RFC 6825 Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS

Authors: M. Miyazawa, T. Otani, K. Kumaki, T. Nadeau.

Date: January 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6825

This memo defines the Management Information Base (MIB) objects for managing the Traffic Engineering Database (TED) information with extensions in support of the Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols.

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 6827 Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols

Authors: A. Malis, Ed., A. Lindem, Ed., D. Papadimitriou, Ed..

Date: January 2013

Formats: txt json html

Obsoletes: RFC 5787

Updates: RFC 5786

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6827

The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH), Optical TransportNetworks (OTNs), and lambda switching optical networks.
The requirements for GMPLS routing to satisfy the requirements ofASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.
Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision ofRFC 4258. This document obsoletes RFC 5787 and updates RFC 5786.

RFC 6828 Content Splicing for RTP Sessions

Authors: J. Xia.

Date: January 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6828

Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement.
This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing.

RFC 6829 Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6

Authors: M. Chen, P. Pan, C. Pignataro, R. Asati.

Date: January 2013

Formats: txt html json

Obsoleted by: RFC 8029

Updates: RFC 4379

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6829

The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)Ping and traceroute mechanisms are commonly used to detect and isolate data-plane failures in all MPLS LSPs, including LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage.
This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6LDP sessions. This document updates RFC 4379.

RFC 6830 The Locator/ID Separation Protocol (LISP)

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 6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments

Authors: D. Farinacci, D. Meyer, J. Zwiebel, S. Venaas.

Date: January 2013

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6831

This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture.

RFC 6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites

Authors: D. Lewis, D. Meyer, D. Farinacci, V. Fuller.

Date: January 2013

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6832

This document describes techniques for allowing sites running theLocator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 orIPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites.This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network AddressTranslation (NAT) functionality to LISP ITRs and LISP Egress TunnelRouters (ETRs) to substitute routable IP addresses for non-routableEIDs. Finally, this document introduces the Proxy Egress TunnelRouter (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation.

RFC 6833 Locator/ID Separation Protocol (LISP) Map-Server Interface

Authors: V. Fuller, D. Farinacci.

Date: January 2013

Formats: txt json html

Obsoleted by: RFC 9301

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6833

This document describes the Mapping Service for the Locator/IDSeparation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID toRouting Locator mapping databases.
By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress TunnelRouters are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs.Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP.

RFC 6834 Locator/ID Separation Protocol (LISP) Map-Versioning

Authors: L. Iannone, D. Saucez, O. Bonaventure.

Date: January 2013

Formats: txt html json

Obsoleted by: RFC 9302

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6834

This document describes the LISP (Locator/ID Separation Protocol)Map-Versioning mechanism, which provides in-packet information aboutEndpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header ofLISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) andEgress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism.

RFC 6835 The Locator/ID Separation Protocol Internet Groper (LIG)

Authors: D. Farinacci, D. Meyer.

Date: January 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6835

A simple tool called the Locator/ID Separation Protocol (LISP)Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works.

RFC 6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)

Authors: V. Fuller, D. Farinacci, D. Meyer, D. Lewis.

Date: January 2013

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6836

This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router(ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular EndpointIdentifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of RoutingLocators (RLOCs) for the EID. Termed the Alternative LogicalTopology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and GenericRouting Encapsulation (GRE).

RFC 6837 NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database

Authors: E. Lear.

Date: January 2013

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6837

The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to-RLOC mappings scales well to at least 10^8 entries.

RFC 6838 Media Type Specifications and Registration Procedures

Authors: N. Freed, J. Klensin, T. Hansen.

Date: January 2013

Formats: txt html json

Obsoletes: RFC 4288

Also: BCP 0013

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6838

This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.

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 6841 A Framework for DNSSEC Policies and DNSSEC Practice Statements

Authors: F. Ljunggren, AM. Eklund Lowinder, T. Okubo.

Date: January 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6841

This document presents a framework to assist writers of DNS SecurityExtensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone withSecurity Extensions implemented.
In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement.

RFC 6842 Client Identifier Option in DHCP Server Replies

Authors: N. Swamy, G. Halwasia, P. Jhingran.

Date: January 2013

Formats: txt html json

Updates: RFC 2131

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6842

This document updates RFC 2131 "Dynamic Host Configuration Protocol" by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client.

RFC 6843 RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting

Authors: A. Clark, K. Gross, Q. Wu.

Date: January 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6843

This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications.

RFC 6844 DNS Certification Authority Authorization (CAA) Resource Record

Authors: P. Hallam-Baker, R. Stradling.

Date: January 2013

Formats: txt json html

Obsoleted by: RFC 8659

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6844

The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more CertificationAuthorities (CAs) authorized to issue certificates for that domain.CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers.

RFC 6845 OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type

Authors: N. Sheth, L. Wang, J. Zhang.

Date: January 2013

Formats: txt json html

Updates: RFC 2328, RFC 5340

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6845

This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes ofOSPF operation. Neighbor discovery and maintenance as well as LinkState Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.
This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340).

RFC 6846 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)

Authors: G. Pelletier, K. Sandlund, L-E. Jonsson, M. West.

Date: January 2013

Formats: txt html json

Obsoletes: RFC 4996

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6846

This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps.
ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.
This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used.

RFC 6847 Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL)

Authors: D. Melman, T. Mizrahi, D. Eastlake 3rd.

Date: January 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6847

Fibre Channel over Ethernet (FCoE) and Transparent Interconnection ofLots of Links (TRILL) are two emerging standards in the data center environment. While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's MediaAccess Control (MAC) addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols.

RFC 6848 Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)

Authors: J. Winterbottom, M. Thomson, R. Barnes, B. Rosen, R. George.

Date: January 2013

Formats: txt json html

Updates: RFC 4776, RFC 5222

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6848

New fields are occasionally added to civic addresses. A backward- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Initial extensions for some new elements are also defined. The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process.

RFC 6849 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback

Authors: H. Kaplan, Ed., K. Hedayat, N. Venna, P. Jones, N. Stratton.

Date: February 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6849

The wide deployment of Voice over IP (VoIP), real-time text, andVideo over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, real- time text, or Video over IP service. Today, in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new Session Description Protocol (SDP) media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, real-time text, and Video over IP performance metrics.

RFC 6850 Definitions of Managed Objects for Routing Bridges (RBridges)

Authors: A. Rijhsinghani, K. Zebrose.

Date: January 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6850

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a Routing Bridge (RBridge), also known as aTRILL Switch, based on the IETF TRILL (Transparent Interconnection ofLots of Links) protocol.

RFC 6851 Internet Message Access Protocol (IMAP) - MOVE Extension

Authors: A. Gulbrandsen, N. Freed, Ed..

Date: January 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6851

This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another.

RFC 6852 Affirmation of the Modern Paradigm for Standards

Authors: R. Housley, S. Mills, J. Jaffe, B. Aboba, L. St.Amour.

Date: January 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6852

On 29 August 2012, the leaders of the IEEE Standards Association, theIAB, the IETF, the Internet Society, and the W3C signed a statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards. These principles have become known as the "OpenStand" principles. This document contains the text of the affirmation that was signed.

RFC 6853 DHCPv6 Redundancy Deployment Considerations

Authors: J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski.

Date: February 2013

Formats: txt html json

Also: BCP 0180

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6853

This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services.

RFC 6854 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields

Authors: B. Leiba.

Date: March 2013

Formats: txt json html

Updates: RFC 5322

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6854

The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or"Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in"Resent-From:" and "Resent-Sender:", in certain situations.

RFC 6855 IMAP Support for UTF-8

Authors: P. Resnick, Ed., C. Newman, Ed., S. Shen, Ed..

Date: March 2013

Formats: txt json html

Obsoletes: RFC 5738

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6855

This specification extends the Internet Message Access Protocol(IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738.

RFC 6856 Post Office Protocol Version 3 (POP3) Support for UTF-8

Authors: R. Gellens, C. Newman, J. Yao, K. Fujiwara.

Date: March 2013

Formats: txt html json

Obsoletes: RFC 5721

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6856

This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings.

RFC 6857 Post-Delivery Message Downgrading for Internationalized Email Messages

Authors: K. Fujiwara.

Date: March 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6857

The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.

RFC 6858 Simplified POP and IMAP Downgrading for Internationalized Email

Authors: A. Gulbrandsen.

Date: March 2013

Formats: txt json html

Updates: RFC 3501

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6858

This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results.

RFC 6859 Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership

Authors: B. Leiba.

Date: January 2013

Formats: txt json html

Obsoleted by: RFC 7437

Updates: RFC 3777

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6859

RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee". Since the time that document was written, the IETF Administrative OversightCommittee (IAOC) was formed; that body is not covered by RFC 3777.There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members". This document updates RFC 3777 to clarify the rules as they apply to members of theIAB, the IESG, and the IAOC.

RFC 6860 Hiding Transit-Only Networks in OSPF

Authors: Y. Yang, A. Retana, A. Roy.

Date: January 2013

Formats: txt json html

Updates: RFC 2328, RFC 5340

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6860

A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link StateAdvertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.
In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2.
This document updates RFCs 2328 and 5340.

RFC 6861 The "create-form" and "edit-form" Link Relations

Authors: I. Dzmanashvili.

Date: January 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6861

RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions.

RFC 6862 Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements

Authors: G. Lebovitz, M. Bhatia, B. Weis.

Date: March 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6862

Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying andAuthentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed. This document is a companion document to RFC 6518, "Keying and Authentication for RoutingProtocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.

RFC 6863 Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide

Authors: S. Hartman, D. Zhang.

Date: March 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6863

This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication forRouting Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.

RFC 6864 Updated Specification of the IPv4 ID Field

Authors: J. Touch.

Date: February 2013

Formats: txt json html

Updates: RFC 0791, RFC 1122, RFC 2003

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6864

The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used.

RFC 6865 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME

Authors: V. Roca, M. Cunche, J. Lacan, A. Bouabdallah, K. Matsuzono.

Date: February 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6865

This document describes a fully-specified simple Forward ErrorCorrection (FEC) scheme for Reed-Solomon codes over the finite field(also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.

RFC 6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks

Authors: B. Carpenter, S. Jiang.

Date: February 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6866

This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.

RFC 6867 An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)

Authors: Y. Nir, Q. Wu.

Date: January 2013

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6867

This document updates the Internet Key Exchange Protocol version 2(IKEv2) described in RFC 5996. This extension allows an IKE SecurityAssociation (SA) to be created and authenticated using the ExtensibleAuthentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696.

RFC 6868 Parameter Value Encoding in iCalendar and vCard

Authors: C. Daboo.

Date: February 2013

Formats: txt json html

Updates: RFC 5545, RFC 6321, RFC 6350, RFC 6351

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6868

This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications.

RFC 6869 vCard KIND:device

Authors: G. Salgueiro, J. Clarke, P. Saint-Andre.

Date: February 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6869

This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone).

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 6871 Session Description Protocol (SDP) Media Capabilities Negotiation

Authors: R. Gilman, R. Even, F. Andreasen.

Date: February 2013

Formats: txt json html

Updates: RFC 5939

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6871

Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP.The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.
This document updates the IANA Considerations of RFC 5939.

RFC 6872 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model

Authors: V. Gurbani, Ed., E. Burger, Ed., T. Anjali, H. Abdelnur, O. Festor.

Date: February 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6872

Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends.Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of aSIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.

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 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers

Authors: B. Carpenter, S. Cheshire, R. Hinden.

Date: February 2013

Formats: txt json html

Updates: RFC 3986

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6874

This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id&rt; in the IPv6 Scoped Address Architecture(RFC 4007), can be represented in a literal IPv6 address and in aUniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.

RFC 6875 The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan

Authors: S. Kamei, T. Momose, T. Inoue, T. Nishitani.

Date: February 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6875

This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic. These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure. Based on what was learned from these experiments, this document provides some suggestions that might be useful for theALTO architecture and especially for application-independent ALTO- like server operation.

RFC 6876 A Posture Transport Protocol over TLS (PT-TLS)

Authors: P. Sangster, N. Cam-Winget, J. Salowey.

Date: February 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6876

This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network EndpointAssessment (NEA) message exchange under the protection of a TransportLayer Security (TLS) secured tunnel.

RFC 6877 464XLAT: Combination of Stateful and Stateless Translation

Authors: M. Mawatari, M. Kawashima, C. Byrne.

Date: April 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6877

This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.

RFC 6878 IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field

Authors: A.B. Roach.

Date: March 2013

Formats: txt json html

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6878

This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261.

RFC 6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods

Authors: S. Jiang, B. Liu, B. Carpenter.

Date: February 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6879

This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.

RFC 6880 An Information Model for Kerberos Version 5

Authors: L. Johansson.

Date: March 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6880

This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a Kerberos 5 Key Distribution Center(KDC). This document describes the services exposed by an administrative interface to a KDC.

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 6882 Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)

Authors: K. Kumaki, Ed., T. Murai, D. Cheng, S. Matsushima, P. Jiang.

Date: March 2013

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6882

IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated usingBGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.
The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs.

RFC 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers

Authors: B. Carpenter, S. Jiang.

Date: March 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6883

This document provides guidance and suggestions for Internet ContentProviders and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users.

RFC 6884 RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)

Authors: Z. Fang.

Date: March 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6884

This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-WidebandCodec (EVRC-NW). Three media type registrations are included forEVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email.

RFC 6885 Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)

Authors: M. Blanchet, A. Sullivan.

Date: March 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6885

If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow. Internationalizing DomainNames in Applications (here called IDNA2003) defined and usedStringprep and Nameprep. Other protocols subsequently definedStringprep profiles. A new approach different from Stringprep andNameprep is used for a revision of IDNA2003 (called IDNA2008). OtherStringprep profiles need to be similarly updated, or a replacement ofStringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement.

RFC 6886 NAT Port Mapping Protocol (NAT-PMP)

Authors: S. Cheshire, M. Krochmal.

Date: April 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6886

This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it.From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol(PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.

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 6888 Common Requirements for Carrier-Grade NATs (CGNs)

Authors: S. Perreault, Ed., I. Yamagata, S. Miyakawa, A. Nakagawa, H. Ashida.

Date: April 2013

Formats: txt json html

Updates: RFC 4787

Also: BCP 0127

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6888

This document defines common requirements for Carrier-Grade NATs(CGNs). It updates RFC 4787.

RFC 6889 Analysis of Stateful 64 Translation

Authors: R. Penno, T. Saxena, M. Boucadair, S. Sivakumar.

Date: April 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6889

Due to specific problems, Network Address Translation - ProtocolTranslation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.

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 6891 Extension Mechanisms for DNS (EDNS(0))

Authors: J. Damas, M. Graff, P. Vixie.

Date: April 2013

Formats: txt json html

Obsoletes: RFC 2671, RFC 2673

Also: STD 0075

Status: INTERNET STANDARD

DOI: 10.17487/RFC 6891

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.
This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletesRFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.

RFC 6892 The 'describes' Link Relation Type

Authors: E. Wilde.

Date: March 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6892

This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.

RFC 6893 A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF)

Authors: P. Higgs, P. Szucs.

Date: March 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6893

This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications. 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 the OIPF.

RFC 6894 Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection

Authors: R. Papneja, S. Vapiwala, J. Karthik, S. Poretsky, S. Rao, JL. Le Roux.

Date: March 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6894

This document describes the methodology for benchmarking MPLS FastReroute (FRR) protection mechanisms for link and node protection.This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS TrafficEngineered (MPLS-TE) tunnels.

RFC 6895 Domain Name System (DNS) IANA Considerations

Authors: D. Eastlake 3rd.

Date: April 2013

Formats: txt json html

Obsoletes: RFC 6195

Updates: RFC 1183, RFC 2845, RFC 2930, RFC 3597

Also: BCP 0042

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6895

This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain NameSystem (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.

RFC 6896 SCS: KoanLogic's Secure Cookie Sessions for HTTP

Authors: S. Barbato, S. Dorigotti, T. Fossati, Ed..

Date: March 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6896

This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin- timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.
Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content viaHTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, HomeOffice (SOHO) routers) or web servers with high availability or load- balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering.

RFC 6897 Multipath TCP (MPTCP) Application Interface Considerations

Authors: M. Scharf, A. Ford.

Date: March 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6897

Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications.Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.

RFC 6898 Link Management Protocol Behavior Negotiation and Configuration Modifications

Authors: D. Li, D. Ceccarelli, L. Berger.

Date: March 2013

Formats: txt json html

Updates: RFC 4204, RFC 4207, RFC 4209, RFC 5818

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6898

The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled byGeneralized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations.
This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.

RFC 6901 JavaScript Object Notation (JSON) Pointer

Authors: P. Bryan, Ed., K. Zyp, M. Nottingham, Ed..

Date: April 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6901

JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.

RFC 6902 JavaScript Object Notation (JSON) Patch

Authors: P. Bryan, Ed., M. Nottingham, Ed..

Date: April 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6902

JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation(JSON) document; it is suitable for use with the HTTP PATCH method.The "application/json-patch+json" media type is used to identify such patch documents.

RFC 6903 Additional Link Relation Types

Authors: J. Snell.

Date: March 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6903

This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.

RFC 6904 Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)

Authors: J. Lennox.

Date: April 2013

Formats: txt json html

Updates: RFC 3711

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6904

The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-timeTransport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.
This document updates RFC 3711, the Secure Real-time TransportProtocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.

RFC 6905 Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)

Authors: T. Senevirathne, D. Bond, S. Aldrin, Y. Li, R. Watve.

Date: March 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6905

Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to theTransparent Interconnection of Lots of Links (TRILL).

RFC 6906 The 'profile' Link Relation Type

Authors: E. Wilde.

Date: March 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6906

This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.

RFC 6907 Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties

Authors: T. Manderson, K. Sriram, R. White.

Date: March 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6907

This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure(RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.

RFC 6908 Deployment Considerations for Dual-Stack Lite

Authors: Y. Lee, R. Maglione, C. Williams, C. Jacquenet, M. Boucadair.

Date: March 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6908

This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture.

RFC 6909 IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6

Authors: S. Gundavelli, Ed., X. Zhou, J. Korhonen, G. Feige, R. Koodli.

Date: April 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6909

This specification defines a new mobility option, the IPv4 TrafficOffload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session.Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network.

RFC 6910 Completion of Calls for the Session Initiation Protocol (SIP)

Authors: D. Worley, M. Huelsemann, R. Jesske, D. Alexeitsev.

Date: April 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6910

The "completion of calls" feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call.
For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'Automatic Redial' in "Session InitiationProtocol Service Examples" (RFC 5359).
For the realization of a more comprehensive solution with queuing, this document introduces an architecture for implementing these features in the Session Initiation Protocol where "completion of calls" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for completion of calls into a queue at the callee's endpoint; when a caller's request is ready to be serviced, re-attempt of the original, failed call is then made.
The architecture is designed to interoperate well with existing completion of calls solutions in other networks.

RFC 6911 RADIUS Attributes for IPv6 Access Networks

Authors: W. Dec, Ed., B. Sarikaya, G. Zorn, Ed., D. Miles, B. Lourdelet.

Date: April 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6911

This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a hostIPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing.

RFC 6912 Principles for Unicode Code Point Inclusion in Labels in the DNS

Authors: A. Sullivan, D. Thaler, J. Klensin, O. Kolkman.

Date: April 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6912

Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points.Most operators of zones should probably not permit registration ofU-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone.

RFC 6913 Indicating Fax over IP Capability in the Session Initiation Protocol (SIP)

Authors: D. Hanes, G. Salgueiro, K. Fleming.

Date: March 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6913

This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP).Currently, fax calls are indistinguishable from voice calls at call initiation. Consequently, fax calls can be routed to SIP user agents that are not fax capable. A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing.

RFC 6914 SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)

Authors: J. Rosenberg.

Date: April 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6914

The IETF has produced many specifications related to Presence andInstant Messaging with the Session Initiation Protocol (SIP).Collectively, these specifications are known as SIP for InstantMessaging and Presence Leveraging Extensions (SIMPLE). This document serves as a guide to the SIMPLE suite of specifications. It categorizes the specifications, explains what each is for, and how they relate to each other.

RFC 6915 Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)

Authors: R. Bellis.

Date: April 2013

Formats: txt json html

Updates: RFC 6155

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6915

RFC 6155 specifies an extension for the HTTP-Enabled LocationDelivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.
However, certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request.
This document specifies an XML Schema and a URN Sub-Namespace for aFlow Identity Extension for HELD to support this requirement.
This document updates RFC 6155 by deprecating the port number elements specified therein.

RFC 6916 Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)

Authors: R. Gagliano, S. Kent, S. Turner.

Date: April 2013

Formats: txt html json

Also: BCP 0182

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6916

This document specifies the process that Certification Authorities(CAs) and Relying Parties (RPs) participating in the Resource PublicKey Infrastructure (RPKI) will need to follow to transition to a new(and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years.Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration(parent migrates before children).

RFC 6917 Media Resource Brokering

Authors: C. Boulton, L. Miniero, G. Munson.

Date: April 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6917

The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol(SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of ApplicationServers and Media Servers. This document introduces a Media ResourceBroker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers.

RFC 6918 Formally Deprecating Some ICMPv4 Message Types

Authors: F. Gont, C. Pignataro.

Date: April 2013

Formats: txt json html

Obsoletes: RFC 1788

Updates: RFC 0792, RFC 0950

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6918

A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletesRFC 1788, and requests the RFC Editor to change the status of RFC1788 to Historic.

RFC 6919 Further Key Words for Use in RFCs to Indicate Requirement Levels

Authors: R. Barnes, S. Kent, E. Rescorla.

Date: 1 April 2013

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6919

RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER","REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO","COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.

RFC 6920 Naming Things with Hashes

Authors: S. Farrell, D. Kutscher, C. Dannewitz, B. Ohlman, A. Keranen, P. Hallam-Baker.

Date: April 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6920

This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these toHTTP URLs, and binary and human-speakable formats for these names.The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.

RFC 6921 Design Considerations for Faster-Than-Light (FTL) Communication

Authors: R. Hinden.

Date: 1 April 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6921

We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues.

RFC 6922 The application/sql Media Type

Authors: Y. Shafranovich.

Date: April 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6922

This document registers the application/sql media type to be used for the Structured Query Language (SQL).

RFC 6923 MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions

Authors: R. Winter, E. Gray, H. van Helvoort, M. Betts.

Date: May 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6923

This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP).Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union TelecommunicationStandardization Sector (ITU-T).

RFC 6924 Registration of Second-Level URN Namespaces under "ietf"

Authors: B. Leiba.

Date: April 2013

Formats: txt json html

Updates: RFC 2648

Status: INFORMATIONAL

DOI: 10.17487/RFC 6924

RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of"ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf".

RFC 6925 The DHCPv4 Relay Agent Identifier Sub-Option

Authors: B. Joshi, R. Desetti, M. Stapp.

Date: April 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6925

This document defines a new Relay Agent Identifier sub-option for theDynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub- option allows a DHCP relay agent to include the identifier in theDHCP messages it sends.

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 6927 Variants in Second-Level Names Registered in Top-Level Domains

Authors: J. Levine, P. Hoffman.

Date: May 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6927

Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS.Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants. This document is not a product of theIETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA.

RFC 6928 Increasing TCP's Initial Window

Authors: J. Chu, N. Dukkipati, Y. Cheng, M. Mathis.

Date: April 2013

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6928

This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified inRFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.

RFC 6929 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions

Authors: A. DeKok, A. Lior.

Date: April 2013

Formats: txt json html

Updates: RFC 2865, RFC 3575, RFC 6158

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6929

The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.

RFC 6930 RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

Authors: D. Guo, S. Jiang, Ed., R. Despres, R. Maglione.

Date: April 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6930

The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides bothIPv4 and IPv6 connectivity services simultaneously during theIPv4/IPv6 coexistence period. The Dynamic Host ConfigurationProtocol (DHCP) 6rd option has been defined to configure the 6rdCustomer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization andAccounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol.This document defines a Remote Authentication Dial-In User Service(RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.

RFC 6931 Additional XML Security Uniform Resource Identifiers (URIs)

Authors: D. Eastlake 3rd.

Date: April 2013

Formats: txt json html

Obsoletes: RFC 4051

Obsoleted by: RFC 9231

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6931

This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051.

RFC 6932 Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry

Authors: D. Harkins, Ed..

Date: May 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6932

This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols.

RFC 6933 Entity MIB (Version 4)

Authors: A. Bierman, D. Romascanu, J. Quittek, M. Chandramouli.

Date: May 2013

Formats: txt html json

Obsoletes: RFC 4133

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6933

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SimpleNetwork Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of theEntity MIB module published as RFC 4133.

RFC 6934 Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)

Authors: N. Bitar, Ed., S. Wadhwa, Ed., T. Haag, H. Li.

Date: June 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6934

The purpose of this document is to provide applicability of theAccess Node Control Mechanism to broadband access based on PassiveOptical Networks (PONs). The need for an Access Node ControlMechanism between a Network Access Server (NAS) and an Access NodeComplex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access NodeControl Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node ControlMechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives.

RFC 6935 IPv6 and UDP Checksums for Tunneled Packets

Authors: M. Eubanks, P. Chimento, M. Westerlund.

Date: April 2013

Formats: txt json html

Updates: RFC 2460

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6935

This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing theIPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried.Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.

RFC 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums

Authors: G. Fairhurst, M. Westerlund.

Date: April 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6936

This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.

RFC 6937 Proportional Rate Reduction for TCP

Authors: M. Mathis, N. Dukkipati, Y. Cheng.

Date: May 2013

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6937

This document describes an experimental Proportional Rate Reduction(PRR) algorithm as an alternative to the widely deployed FastRecovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.

RFC 6938 Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID

Authors: J. Scudder.

Date: May 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6938

This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC.

RFC 6939 Client Link-Layer Address Option in DHCPv6

Authors: G. Halwasia, S. Bhandari, W. Dec.

Date: May 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6939

This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option.

RFC 6940 REsource LOcation And Discovery (RELOAD) Base Protocol

Authors: C. Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne.

Date: January 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6940

This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. AP2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P SessionInitiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.

RFC 6941 MPLS Transport Profile (MPLS-TP) Security Framework

Authors: L. Fang, Ed., B. Niven-Jenkins, Ed., S. Mansfield, Ed., R. Graveman, Ed..

Date: April 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6941

This document provides a security framework for the MPLS TransportProfile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context ofMPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and toMPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLSNetworks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply.
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 functionality of a packet transport network.

RFC 6942 Diameter Support for the EAP Re-authentication Protocol (ERP)

Authors: J. Bournelle, L. Morand, S. Decugis, Q. Wu, G. Zorn.

Date: May 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6942

The EAP Re-authentication Protocol (ERP) defines extensions to theExtensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifiesDiameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server.

RFC 6943 Issues in Identifier Comparison for Security Purposes

Authors: D. Thaler, Ed..

Date: May 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6943

Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.

RFC 6944 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status

Authors: S. Rose.

Date: April 2013

Formats: txt html json

Obsoleted by: RFC 8624

Updates: RFC 2536, RFC 2539, RFC 3110, RFC 4034, RFC 4398, RFC 5155, RFC 5702, RFC 5933

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6944

The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures overDNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.

RFC 6945 Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol

Authors: R. Bush, B. Wijnen, K. Patel, M. Baer.

Date: May 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6945

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol.

RFC 6946 Processing of IPv6 "Atomic" Fragments

Authors: F. Gont.

Date: May 2013

Formats: txt json html

Updates: RFC 2460, RFC 5722

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6946

The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal"fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.

RFC 6947 The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute

Authors: M. Boucadair, H. Kaplan, R. Gilman, S. Veikkolainen.

Date: May 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6947

This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative NetworkAddress Types (ANAT) due to their syntax.
The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required,Interactive Connectivity Establishment (ICE), as specified in RFC5245, provides such a solution.

RFC 6948 Some Measurements on World IPv6 Day from an End-User Perspective

Authors: A. Keranen, J. Arkko.

Date: July 2013

Formats: txt html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6948

During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services.Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.

RFC 6949 RFC Series Format Requirements and Future Development

Authors: H. Flanagan, N. Brownlee.

Date: May 2013

Formats: txt html json

Updates: RFC 2223

Status: INFORMATIONAL

DOI: 10.17487/RFC 6949

This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223.

RFC 6950 Architectural Considerations on Application Features in the DNS

Authors: J. Peterson, O. Kolkman, H. Tschofenig, B. Aboba.

Date: October 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6950

A number of Internet applications rely on the Domain Name System(DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.

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 6952 Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide

Authors: M. Jethanandani, K. Patel, L. Zheng.

Date: May 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6952

This document analyzes TCP-based routing protocols, the BorderGateway Protocol (BGP), the Label Distribution Protocol (LDP), thePath Computation Element Communication Protocol (PCEP), and theMulticast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication forRouting Protocols Design Guidelines", RFC 6518.

RFC 6953 Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements

Authors: A. Mancuso, Ed., S. Probasco, B. Patil.

Date: May 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6953

Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented.

RFC 6954 Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: J. Merkle, M. Lochter.

Date: July 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6954

This document specifies use of the Elliptic Curve Cryptography (ECC)Brainpool elliptic curve groups for key exchange in the Internet KeyExchange Protocol version 2 (IKEv2).

RFC 6955 Diffie-Hellman Proof-of-Possession Algorithms

Authors: J. Schaad, H. Prafullchandra.

Date: May 2013

Formats: txt html json

Obsoletes: RFC 2875

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6955

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.
This document obsoletes RFC 2875.

RFC 6956 Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library

Authors: W. Wang, E. Haleplidis, K. Ogawa, C. Li, J. Halpern.

Date: June 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6956

This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES ForwardingElement (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions.

RFC 6957 Duplicate Address Detection Proxy

Authors: F. Costa, J-M. Combes, Ed., X. Pougnard, H. Li.

Date: June 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6957

The document describes a proxy-based mechanism allowing the use ofDuplicate Address Detection (DAD) by IPv6 nodes in a point-to- multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point- to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address.

RFC 6958 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting

Authors: A. Clark, S. Zhang, J. Zhao, Q. Wu, Ed..

Date: May 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6958

This document defines an RTP Control Protocol (RTCP) Extended Report(XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications.

RFC 6959 Source Address Validation Improvement (SAVI) Threat Scope

Authors: D. McPherson, F. Baker, J. Halpern.

Date: May 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6959

The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work.

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 6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension

Authors: Y. Pettersen.

Date: June 2013

Formats: txt html json

Obsoleted by: RFC 8446

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6961

This document defines the Transport Layer Security (TLS) CertificateStatus Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the CertificateStatus extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate StatusProtocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.

RFC 6962 Certificate Transparency

Authors: B. Laurie, A. Langley, E. Kasper.

Date: June 2013

Formats: txt json html

Obsoleted by: RFC 9162

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6962

This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcingCAs to add all issued certificates to the logs.
Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

RFC 6963 A Uniform Resource Name (URN) Namespace for Examples

Authors: P. Saint-Andre.

Date: May 2013

Formats: txt json html

Also: BCP 0183

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6963

This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation.

RFC 6964 Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

Authors: F. Templin.

Date: May 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6964

Many end-user sites in the Internet today still have predominantlyIPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using theIntra-Site Automatic Tunnel Addressing Protocol (ISATAP).

RFC 6965 MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design

Authors: L. Fang, Ed., N. Bitar, R. Zhang, M. Daikoku, P. Pan.

Date: August 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6965

This document describes the applicability of the MPLS TransportProfile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport.

RFC 6967 Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments

Authors: M. Boucadair, J. Touch, P. Levis, R. Penno.

Date: June 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6967

This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address.
This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches.

RFC 6968 FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols

Authors: V. Roca, B. Adamson.

Date: July 2013

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6968

This document introduces the FCAST reliable object (e.g., file) delivery application. It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered CodingTransport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol.

RFC 6969 OSPFv3 Instance ID Registry Update

Authors: A. Retana, D. Cheng.

Date: July 2013

Formats: txt html json

Updates: RFC 5838

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6969

This document modifies the "Unassigned" number space in the IANA"OSPFv3 Instance ID Address Family Values" registry by dividing it in two halves -- one half Unassigned but managed via Standards Action, and the other Reserved for Private Use. It updates RFC 5838.

RFC 6970 Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)

Authors: M. Boucadair, R. Penno, D. Wing.

Date: July 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6970

This document specifies the behavior of the Universal Plug and Play(UPnP) Internet Gateway Device - Port Control Protocol InterworkingFunction (IGD-PCP IWF). A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparentNAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router.

RFC 6971 Depth-First Forwarding (DFF) in Unreliable Networks

Authors: U. Herberg, Ed., A. Cardenas, T. Iwao, M. Dow, S. Cespedes.

Date: June 2013

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6971

This document specifies the Depth-First Forwarding (DFF) protocol forIPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies theDFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944. The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not. It is applicable for networks with little traffic and is used for unicast transmissions only.

RFC 6972 Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)

Authors: Y. Zhang, N. Zong.

Date: July 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6972

Peer-to-Peer (P2P) streaming systems becoming more and more popular on the Internet, and most of them are using proprietary protocols.This document identifies problems associated with proprietary protocols; proposes the development of the Peer-to-Peer StreamingProtocol (PPSP), which includes the tracker and peer protocols; and discusses the scope, requirements, and use cases of PPSP.

RFC 6973 Privacy Considerations for Internet Protocols

Authors: A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, R. Smith.

Date: July 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6973

This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy- related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.

RFC 6974 Applicability of MPLS Transport Profile for Ring Topologies

Authors: Y. Weingarten, S. Bryant, D. Ceccarelli, D. Caviglia, F. Fondelli, M. Corsi, B. Wu, X. Dai.

Date: July 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6974

This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile(MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in"Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLSTransport Profile (MPLS-TP) Survivability Framework" (RFC 6372).This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology.

RFC 6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)

Authors: S. Crocker, S. Rose.

Date: July 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6975

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 generated using different algorithms. This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in aDNSSEC-signed zone.

RFC 6976 Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach

Authors: M. Shand, S. Bryant, S. Previdi, C. Filsfils, P. Francois, O. Bonaventure.

Date: July 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6976

This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers.
This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes.It can also be used in conjunction with a fast reroute mechanism that converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations.
After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described.
The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.

RFC 6977 Triggering DHCPv6 Reconfiguration from Relay Agents

Authors: M. Boucadair, X. Pougnard.

Date: July 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6977

This document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. The Reconfigure-Request message is sent by aDHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message.

RFC 6978 A TCP Authentication Option Extension for NAT Traversal

Authors: J. Touch.

Date: July 2013

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6978

This document describes an extension to the TCP Authentication Option(TCP-AO) to support its use over connections that pass throughNetwork Address Translators and/or Network Address and PortTranslators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.

RFC 6979 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)

Authors: T. Pornin.

Date: August 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6979

This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard DigitalSignature Algorithm (DSA) and Elliptic Curve Digital SignatureAlgorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.

RFC 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery

Authors: F. Gont.

Date: August 2013

Formats: txt html json

Updates: RFC 3971, RFC 4861

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6980

This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated.

RFC 6981 A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses

Authors: S. Bryant, S. Previdi, M. Shand.

Date: August 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6981

This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.
The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification.The document represents a snapshot of the work of the Routing AreaWorking Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.

RFC 6982 Improving Awareness of Running Code: The Implementation Status Section

Authors: Y. Sheffer, A. Farrel.

Date: July 2013

Formats: txt json html

Obsoleted by: RFC 7942

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6982

This document describes a simple process that allows authors ofInternet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
The process in this document is offered as an experiment. Authors ofInternet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community.

RFC 6983 Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)

Authors: R. van Brandenburg, O. van Deventer, F. Le Faucheur, K. Leung.

Date: July 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6983

This document presents thoughts on the potential impact of supportingHTTP Adaptive Streaming (HAS) technologies in Content DistributionNetwork Interconnection (CDNI) scenarios. The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI.This document has been used as input information during the CDNI working group process for making a decision regarding support forHAS.

RFC 6984 Interoperability Report for Forwarding and Control Element Separation (ForCES)

Authors: W. Wang, K. Ogawa, E. Haleplidis, M. Gao, J. Hadi Salim.

Date: August 2013

Formats: txt html json

Updates: RFC 6053

Status: INFORMATIONAL

DOI: 10.17487/RFC 6984

This document captures the results of the second Forwarding andControl Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China. The results of the firstForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results.

RFC 6985 IMIX Genome: Specification of Variable Packet Sizes for Additional Testing

Authors: A. Morton.

Date: July 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6985

Benchmarking methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with a constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX"("Internet Mix"). The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking device and deployment will not be appropriate for another. However, the mix of sizes may be known, and the tester may be asked to augment the fixed-size tests. To address this need and the perpetual goal of specifying repeatable test conditions, this document defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes and from other forms of mixed-size specification.

RFC 6986 GOST R 34.11-2012: Hash Function

Authors: V. Dolmatov, Ed., A. Degtyarev.

Date: August 2013

Formats: txt json html

Updates: RFC 5831

Status: INFORMATIONAL

DOI: 10.17487/RFC 6986

This document is intended to be a source of information about theRussian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831.

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 6988 Requirements for Energy Management

Authors: J. Quittek, Ed., M. Chandramouli, R. Winter, T. Dietz, B. Claise.

Date: September 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 6988

This document defines requirements for standards specifications forEnergy Management. The requirements defined in this document are concerned with monitoring functions as well as control functions.Monitoring functions include identifying energy-managed devices and their components, as well as monitoring their Power States, PowerInlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and contained batteries. Control functions include such functions as controlling power supply and Power State of energy-managed devices and their components.
This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards for Energy Management.

RFC 6989 Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: Y. Sheffer, S. Fluhrer.

Date: July 2013

Formats: txt html json

Updates: RFC 5996

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6989

This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2(IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996.

RFC 6990 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting

Authors: R. Huang, Q. Wu, H. Asaeda, G. Zorn.

Date: August 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6990

An MPEG-2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/ multicast MPEG-2 TS over RTP is widely deployed in IPTV systems.This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of MPEG-2 TS decodability statistics metrics related to transmissions of MPEG-2 TS over RTP.The metrics specified in the RTCP XR block are not dependent onProgram Specific Information (PSI) carried in MPEG-2 TS.

RFC 6991 Common YANG Data Types

Authors: J. Schoenwaelder, Ed..

Date: July 2013

Formats: txt html json

Obsoletes: RFC 6021

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6991

This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC6021.

RFC 6992 Routing for IPv4-Embedded IPv6 Packets

Authors: D. Cheng, M. Boucadair, A. Retana.

Date: July 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6992

This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described inRFCs 6145 and 6052, along with a separate OSPFv3 routing table forIPv4-embedded IPv6 routes in the IPv6 network.

RFC 6993 Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)

Authors: P. Saint-Andre.

Date: July 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 6993

This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session InitiationProtocol (SIP).

RFC 6994 Shared Use of Experimental TCP Options

Authors: J. Touch.

Date: August 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 6994

This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints.

RFC 6996 Autonomous System (AS) Reservation for Private Use

Authors: J. Mitchell.

Date: July 2013

Formats: txt json html

Updates: RFC 1930

Also: BCP 0006

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 6996

This document describes the reservation of Autonomous System Numbers(ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document.

RFC 6997 Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks

Authors: M. Goyal, Ed., E. Baccelli, M. Philipp, A. Brandt, J. Martocci.

Date: August 2013

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6997

This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and LossyNetworks (RPL) core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints.

RFC 6998 A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network

Authors: M. Goyal, Ed., E. Baccelli, A. Brandt, J. Martocci.

Date: August 2013

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 6998

This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route.

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 7002 RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting

Authors: A. Clark, G. Zorn, Q. Wu.

Date: September 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7002

This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of a simple discard count metric for use in a range of RTP applications.

RFC 7003 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting

Authors: A. Clark, R. Huang, Q. Wu, Ed..

Date: September 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7003

This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications.

RFC 7004 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting

Authors: G. Zorn, R. Schott, Q. Wu, Ed., R. Huang.

Date: September 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7004

This document defines three RTP Control Protocol (RTCP) ExtendedReport (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications.

RFC 7005 RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting

Authors: A. Clark, V. Singh, Q. Wu.

Date: September 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7005

This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications.

RFC 7006 Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)

Authors: M. Garcia-Martin, S. Veikkolainen, R. Gilman.

Date: September 2013

Formats: txt pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7006

The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities.This negotiation is embedded into the widely used SDP offer/answer procedures.
This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth("b=" line), connection data ("c=" line), and session or media titles("i=" line for each session or media).

RFC 7007 Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)

Authors: T. Terriberry.

Date: August 2013

Formats: txt html json

Updates: RFC 3551

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7007

The RTP Profile for Audio and Video Conferences with Minimal Control(RTP/AVP) is the basis for many other profiles, such as the SecureReal-time Transport Protocol (RTP/SAVP), the Extended RTP Profile forReal-time Transport Control Protocol (RTCP)-Based Feedback(RTP/AVPF), and the Extended Secure RTP Profile for RTCP-BasedFeedback (RTP/SAVPF). This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since that document was originally published.

RFC 7008 A Description of the KCipher-2 Encryption Algorithm

Authors: S. Kiyomoto, W. Shin.

Date: August 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7008

This document describes the KCipher-2 encryption algorithm.KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. As of the publication of this document, no security vulnerabilities have been found. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan.

RFC 7009 OAuth 2.0 Token Revocation

Authors: T. Lodderstedt, Ed., S. Dronia, M. Scurtescu.

Date: August 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7009

This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed.This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.

RFC 7010 IPv6 Site Renumbering Gap Analysis

Authors: B. Liu, S. Jiang, B. Carpenter, S. Venaas, W. George.

Date: September 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7010

This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering.The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process.

RFC 7011 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information

Authors: B. Claise, Ed., B. Trammell, Ed., P. Aitken.

Date: September 2013

Formats: txt json html

Obsoletes: RFC 5101

Also: STD 0077

Status: INTERNET STANDARD

DOI: 10.17487/RFC 7011

This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how theIPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIXCollecting Process. This document obsoletes RFC 5101.

RFC 7012 Information Model for IP Flow Information Export (IPFIX)

Authors: B. Claise, Ed., B. Trammell, Ed..

Date: September 2013

Formats: txt html json

Obsoletes: RFC 5102

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7012

This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIXInformation Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic MeteringProcess, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.

RFC 7013 Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements

Authors: B. Trammell, B. Claise.

Date: September 2013

Formats: txt html json

Also: BCP 0184

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7013

This document provides guidelines for how to write definitions of newInformation Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIXInformation Element registry, and provides guidelines for expert reviewers to evaluate new registrations.

RFC 7014 Flow Selection Techniques

Authors: S. D'Antonio, T. Zseby, C. Henke, L. Peluso.

Date: September 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7014

The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate FlowSelection Process may be located at an IP Flow Information Export(IPFIX) Exporter or Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring FlowRecords. This document describes motivations for using theIntermediate Flow Selection process and presents Intermediate FlowSelection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow SelectionProcess should be exported.

RFC 7015 Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol

Authors: B. Trammell, A. Wagner, B. Claise.

Date: September 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7015

This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export(IPFIX) protocol to the handling of Aggregated Flows, which are IPFIXFlows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals.

RFC 7016 Adobe's Secure Real-Time Media Flow Protocol

Authors: M. Thornburgh.

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7016

This memo describes Adobe's Secure Real-Time Media Flow Protocol(RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features that make it effective for peer-to-peer (P2P) as well as client- server communications, even when Network Address Translators (NATs) are used.

RFC 7017 IMAP Access to IETF Email List Archives

Authors: R. Sparks.

Date: August 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7017

The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists.Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching, and it is intended as input to a later activity for the design and development of such a service.

RFC 7018 Auto-Discovery VPN Problem Statement and Requirements

Authors: V. Manral, S. Hanna.

Date: September 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7018

This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution.
Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements.

RFC 7019 Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD)

Authors: J. Buford, M. Kolberg, Ed..

Date: September 2013

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7019

We define a REsource LOcation And Discovery (RELOAD) Usage forApplication-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay- independent way. Two example algorithms are defined, based on Scribe and P2PCast.
This document is a product of the Scalable Adaptive MulticastResearch Group (SAM RG).

RFC 7020 The Internet Numbers Registry System

Authors: R. Housley, J. Curran, G. Huston, D. Conrad.

Date: August 2013

Formats: txt json html

Obsoletes: RFC 2050

Status: INFORMATIONAL

DOI: 10.17487/RFC 7020

This document provides information about the current Internet NumbersRegistry System used in the distribution of globally unique InternetProtocol (IP) address space and autonomous system (AS) numbers.
This document also provides information about the processes for further evolution of the Internet Numbers Registry System.
This document replaces RFC 2050.
This document does not propose any changes to the current InternetNumbers Registry System. Rather, it documents the Internet NumbersRegistry System as it works today.

RFC 7021 Assessing the Impact of Carrier-Grade NAT on Network Applications

Authors: C. Donley, Ed., L. Howard, V. Kuarsingh, J. Berg, J. Doshi.

Date: September 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7021

NAT444 is an IPv4 extension technology being considered by ServiceProviders as a means to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Carrier-Grade NAT (CGN) in the Service Provider network, often resulting in two NATs. CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment. This document identifies areas where adding a second layer of NAT disrupts the communication channel for commonInternet applications. This document was updated to include theDual-Stack Lite (DS-Lite) impacts also.

RFC 7022 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)

Authors: A. Begen, C. Perkins, D. Wing, E. Rescorla.

Date: September 2013

Formats: txt html json

Obsoletes: RFC 6222

Updates: RFC 3550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7022

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While theSynchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.
For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCPCNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC6222.

RFC 7023 MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking

Authors: D. Mohan, Ed., N. Bitar, Ed., A. Sajassi, Ed., S. DeLord, P. Niger, R. Qiu.

Date: October 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7023

This document specifies the mapping of defect states between EthernetAttachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge(PWE3) architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects.

RFC 7024 Virtual Hub-and-Spoke in BGP/MPLS VPNs

Authors: H. Jeng, J. Uttaro, L. Jalil, B. Decraene, Y. Rekhter, R. Aggarwal.

Date: October 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7024

With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each ProviderEdge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.
Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers.

RFC 7025 Requirements for GMPLS Applications of PCE

Authors: T. Otani, K. Ogaki, D. Caviglia, F. Zhang, C. Margaria.

Date: September 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7025

The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE.

RFC 7026 Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel

Authors: A. Farrel, S. Bryant.

Date: September 2013

Formats: txt html json

Updates: RFC 5586

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7026

The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header(ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are calledACH TLVs
No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable.
This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.

RFC 7027 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)

Authors: J. Merkle, M. Lochter.

Date: October 2013

Formats: txt html json

Updates: RFC 4492

Status: INFORMATIONAL

DOI: 10.17487/RFC 7027

This document specifies the use of several Elliptic CurveCryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol.

RFC 7028 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6

Authors: JC. Zuniga, LM. Contreras, CJ. Bernardos, S. Jeon, Y. Kim.

Date: September 2013

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7028

This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile AccessGateway can provide access to multicast content in the local network.The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting differentPMIPv6 deployment scenarios.

RFC 7029 Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding

Authors: S. Hartman, M. Wasserman, D. Zhang.

Date: October 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7029

As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC3748 that protects tunnel methods against man-in-the-middle attacks.However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.

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 7031 DHCPv6 Failover Requirements

Authors: T. Mrugalski, K. Kinnear.

Date: September 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7031

The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. RFC 3315 allows for, but does not define, any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol.

RFC 7032 LDP Downstream-on-Demand in Seamless MPLS

Authors: T. Beckhaus, Ed., B. Decraene, K. Tiruveedhula, M. Konstantynowicz, Ed., L. Martini.

Date: October 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7032

Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDPDownstream-on-Demand (DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design.
In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence.

RFC 7033 WebFinger

Authors: P. Jones, G. Salgueiro, M. Jones, J. Smarr.

Date: September 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7033

This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on theInternet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.

RFC 7034 HTTP Header Field X-Frame-Options

Authors: D. Ross, T. Gondrom.

Date: October 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7034

To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages.

RFC 7035 Relative Location Representation

Authors: M. Thomson, B. Rosen, D. Stanley, G. Bajko, A. Thomson.

Date: October 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7035

This document defines an extension to the Presence Information DataFormat Location Object (PIDF-LO) (RFC 4119) for the expression of location information that is defined relative to a reference point.The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described.
Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system, to allow display of the map with the reference point and the relative offset.

RFC 7036 Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group

Authors: R. Housley.

Date: October 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7036

When the Long-Term Archive and Notary Services (LTANS) working group was chartered, an object identifier arc was set aside for use by that working group. This document describes the object identifiers that were assigned, and it establishes IANA allocation policies for any future assignments within that arc.

RFC 7037 RADIUS Option for the DHCPv6 Relay Agent

Authors: L. Yeh, M. Boucadair.

Date: October 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7037

The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server. This architecture assumes that the NetworkAccess Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client. When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server. TheDHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests.

RFC 7038 Use of OSPF-MDR in Single-Hop Broadcast Networks

Authors: R. Ogier.

Date: October 2013

Formats: txt json html

Updates: RFC 5614

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7038

RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks(MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR (MANETDesignated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor.The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks.

RFC 7039 Source Address Validation Improvement (SAVI) Framework

Authors: J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, Ed..

Date: October 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7039

Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents.

RFC 7040 Public IPv4-over-IPv6 Access Network

Authors: Y. Cui, J. Wu, P. Wu, O. Vautrin, Y. Lee.

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7040

This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows theHub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network. The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay. Public4over6 aims to provide uninterrupted IPv4 services to users, likeInternet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network.

RFC 7041 Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging

Authors: F. Balus, Ed., A. Sajassi, Ed., N. Bitar, Ed..

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7041

The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines an architecture and bridge protocols for interconnection of multipleProvider Bridged Networks (PBNs). Provider backbone bridging was defined by IEEE as a connectionless technology based on multipointVLAN tunnels. PBB can be used to attain better scalability thanProvider Bridges (PBs) in terms of the number of customer MediaAccess Control addresses and the number of service instances that can be supported.
The Virtual Private LAN Service (VPLS) provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running the Rapid SpanningTree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks.
This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the service provider fit of the initial model.

RFC 7042 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Authors: D. Eastlake 3rd, J. Abley.

Date: October 2013

Formats: txt json html

Obsoletes: RFC 5342

Obsoleted by: RFC 9542

Updates: RFC 2153

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7042

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342.

RFC 7043 Resource Records for EUI-48 and EUI-64 Addresses in the DNS

Authors: J. Abley.

Date: October 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7043

48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended UniqueIdentifier (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g., Ethernet.
This document describes two new DNS resource record types, EUI48 andEUI64, for encoding Ethernet addresses in the DNS.
This document describes potentially severe privacy implications resulting from indiscriminate publication of link-layer addresses in the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated.

RFC 7044 An Extension to the Session Initiation Protocol (SIP) for Request History Information

Authors: M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg.

Date: February 2014

Formats: txt html json

Obsoletes: RFC 4244

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7044

This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field.This document obsoletes RFC 4244.

RFC 7045 Transmission and Processing of IPv6 Extension Headers

Authors: B. Carpenter, S. Jiang.

Date: December 2013

Formats: txt html json

Updates: RFC 2460, RFC 2780

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7045

Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.

RFC 7046 A Common API for Transparent Hybrid Multicast

Authors: M. Waehlisch, T. Schmidt, S. Venaas.

Date: December 2013

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7046

Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current MulticastDomains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM)Research Group.

RFC 7047 The Open vSwitch Database Management Protocol

Authors: B. Pfaff, B. Davie, Ed..

Date: December 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7047

Open vSwitch is an open-source software switch designed to be used as a vswitch (virtual switch) in virtualized server environments. A vswitch forwards traffic between different virtual machines (VMs) on the same physical host and also forwards traffic between VMs and the physical network. Open vSwitch is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol. This document defines the OVSDB management protocol. The Open vSwitch project includes open-source OVSDB client and server implementations.

RFC 7048 Neighbor Unreachability Detection Is Too Impatient

Authors: E. Nordmark, I. Gashinsky.

Date: January 2014

Formats: txt html json

Updates: RFC 4861

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7048

IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.That function is very useful when a host has an alternative neighbor-- for instance, when there are multiple default routers -- since it allows the host to switch to the alternative neighbor in a short time. By default, this time is 3 seconds after the node starts probing. However, if there are no alternative neighbors, this timeout behavior is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC4861.

RFC 7049 Concise Binary Object Representation (CBOR)

Authors: C. Bormann, P. Hoffman.

Date: October 2013

Formats: txt html json

Obsoleted by: RFC 8949

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7049

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.

RFC 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 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix

Authors: J. Korhonen, Ed., T. Savolainen, Ed..

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7051

Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by theNAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the approach based on heuristic discovery.

RFC 7052 Locator/ID Separation Protocol (LISP) MIB

Authors: G. Schudel, A. Jain, V. Moreno.

Date: October 2013

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7052

This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol(LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information,LISP functional status, and operational counters and other statistics.

RFC 7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol

Authors: M. Tuexen, I. Ruengeler, R. Stewart.

Date: November 2013

Formats: txt json html

Obsoleted by: RFC 9260

Updates: RFC 4960

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7053

This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding SelectiveAcknowledgment (SACK) chunk should be sent back immediately and should not be delayed. It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems.

RFC 7054 Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs)

Authors: A. Farrel, H. Endo, R. Winter, Y. Koike, M. Paul.

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7054

The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how theMaintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces.
This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine.Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP.

RFC 7055 A GSS-API Mechanism for the Extensible Authentication Protocol

Authors: S. Hartman, Ed., J. Howlett.

Date: December 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7055

This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security ServiceApplication Program Interface (GSS-API) when using the ExtensibleAuthentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define howSimple Authentication and Security Layer (SASL) applications use theExtensible Authentication Protocol.

RFC 7056 Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism

Authors: S. Hartman, J. Howlett.

Date: December 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7056

The naming extensions to the Generic Security Service ApplicationProgramming Interface (GSS-API) provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication, Authorization, and Accounting(AAA) peer to provide authorization attributes alongside an authentication response. It also supplies mechanisms to processSecurity Assertion Markup Language (SAML) messages provided in theAAA response. This document describes how to use the NamingExtensions API to access that information.

RFC 7057 Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)

Authors: S. Winter, J. Salowey.

Date: December 2013

Formats: txt json html

Updates: RFC 3748

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7057

This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of theEAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture.

RFC 7058 Media Control Channel Framework (CFW) Call Flow Examples

Authors: A. Amirante, T. Castaldi, L. Miniero, S P. Romano.

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7058

This document provides a list of typical Media Control ChannelFramework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based MediaServers, as well as a base reference document for both implementors and protocol researchers.

RFC 7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms

Authors: S. Steffann, I. van Beijnum, R. van Rein.

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7059

This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them.

RFC 7060 Using LDP Multipoint Extensions on Targeted LDP Sessions

Authors: M. Napierala, E. Rosen, IJ. Wijnands.

Date: November 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7060

Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label SwitchedPaths. However, the specification for the Multipoint Extensions toLDP presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP Multipoint Extensions over aTargeted LDP session.

RFC 7061 eXtensible Access Control Markup Language (XACML) XML Media Type

Authors: R. Sinnema, E. Wilde.

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7061

This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML).

RFC 7062 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks

Authors: F. Zhang, Ed., D. Li, H. Li, S. Belotti, D. Ceccarelli.

Date: November 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7062

This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol LabelSwitching (GMPLS) and Path Computation Element (PCE) control ofOptical Transport Networks (OTNs) as specified in ITU-TRecommendation G.709 as published in 2012.

RFC 7063 Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments

Authors: L. Zheng, J. Zhang, R. Parekh.

Date: December 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7063

This document provides supporting documentation to advance the IETF stream's Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from Proposed Standard to Internet Standard.

RFC 7064 URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol

Authors: S. Nandakumar, G. Salgueiro, P. Jones, M. Petit-Huguenin.

Date: November 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7064

This document specifies the syntax and semantics of the UniformResource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol.

RFC 7065 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers

Authors: M. Petit-Huguenin, S. Nandakumar, G. Salgueiro, P. Jones.

Date: November 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7065

This document specifies the syntax of Uniform Resource Identifier(URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURNResolution Mechanism (RFC 5928).

RFC 7066 IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts

Authors: J. Korhonen, Ed., J. Arkko, Ed., T. Savolainen, S. Krishnan.

Date: November 2013

Formats: txt json html

Obsoletes: RFC 3316

Status: INFORMATIONAL

DOI: 10.17487/RFC 7066

As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the InternetProtocol version 6 (IPv6) mandatory in their specifications.However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), UniversalMobile Telecommunications System (UMTS), or Evolved Packet System(EPS) networks (hereafter collectively referred to as ThirdGeneration Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316.

RFC 7067 Directory Assistance Problem and High-Level Design Proposal

Authors: L. Dunbar, D. Eastlake 3rd, R. Perlman, I. Gashinsky.

Date: November 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7067

Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC (Media Access Control) addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End-Station AddressDistribution Information) protocol. When an ingress TRILL switch receives a data frame for a destination address (MAC&Label) that the switch does not know, the data frame is flooded within the frame'sData Label across the TRILL campus.
This document describes the framework for using directory services to assist edge TRILL switches in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND (AddressResolution Protocol / Neighbor Discovery), thus improving TRILL network scalability and security.

RFC 7068 Diameter Overload Control Requirements

Authors: E. McMurry, B. Campbell.

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7068

When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing Diameter mechanisms are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided.

RFC 7069 DECoupled Application Data Enroute (DECADE)

Authors: R. Alimi, A. Rahman, D. Kutscher, Y. Yang, H. Song, K. Pentikousis.

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7069

Content distribution applications, such as those employing peer-to- peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks. Often, however, content distribution applications use network resources inefficiently. One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end- host and in-network content distribution mechanisms. This is the capability provided by a DECoupled Application Data Enroute (DECADE) system, which is introduced in this document. DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources. This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples.

RFC 7070 An Architecture for Reputation Reporting

Authors: N. Borenstein, M. Kucherawy.

Date: November 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7070

This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over theInternet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC 4101 for describing a protocol model.

RFC 7071 A Media Type for Reputation Interchange

Authors: N. Borenstein, M. Kucherawy.

Date: November 2013

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7071

This document defines the format of reputation response data("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets.

RFC 7072 A Reputation Query Protocol

Authors: N. Borenstein, M. Kucherawy.

Date: November 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7072

This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) usingJavaScript Object Notation (JSON) as the payload meta-format.

RFC 7073 A Reputation Response Set for Email Identifiers

Authors: N. Borenstein, M. Kucherawy.

Date: November 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7073

This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.

RFC 7074 Revised Definition of the GMPLS Switching Capability and Type Fields

Authors: L. Berger, J. Meuric.

Date: November 2013

Formats: txt html json

Updates: RFC 3471, RFC 4202, RFC 4203, RFC 5307

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7074

GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via theSwitching Capability field, and in signaling protocols via theSwitching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of theSwitching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs3471, 4202, 4203, and 5307.

RFC 7075 Realm-Based Redirection In Diameter

Authors: T. Tsou, R. Hao, T. Taylor, Ed..

Date: November 2013

Formats: txt html json

Updates: RFC 6733

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7075

The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when theStraightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server".
This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-TimeAttribute-Value Pairs (AVPs).

RFC 7076 P6R's Secure Shell Public Key Subsystem

Authors: M. Joseph, J. Susoy.

Date: November 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7076

The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.
The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key ManagementInteroperability Protocol (KMIP), Simple Network Management Protocol(SNMP)).
The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).
Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819.

RFC 7077 Update Notifications for Proxy Mobile IPv6

Authors: S. Krishnan, S. Gundavelli, M. Liebsch, H. Yokota, J. Korhonen.

Date: November 2013

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7077

This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These Update Notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose.

RFC 7078 Distributing Address Selection Policy Using DHCPv6

Authors: A. Matsumoto, T. Fujisaki, T. Chown.

Date: January 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7078

RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus allowing the administrator to control the address selection behavior of nodes in their site.

RFC 7079 The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results

Authors: N. Del Regno, Ed., A. Malis, Ed..

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7079

The IETF Pseudowire Emulation Edge-to-Edge (PWE3) working group has defined many encapsulations of various layer 1 and layer 2 service- specific PDUs and circuit data. In most of these encapsulations, use of the Pseudowire (PW) Control Word is required. However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations. This survey of the Pseudowire / Virtual CircuitConnectivity Verification (VCCV) user community was conducted to determine implementation trends and the possibility of always mandating the Control Word.

RFC 7080 Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges

Authors: A. Sajassi, S. Salam, N. Bitar, F. Balus.

Date: December 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7080

The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) with Ethernet access networks (RFC 4762) can be improved by incorporating Provider Backbone Bridge functionality in the VPLS access. Provider Backbone Bridging has been standardized as IEEE802.1ah-2008. It aims to improve the scalability of Media AccessControl (MAC) addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used inH-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access.

RFC 7081 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)

Authors: E. Ivov, P. Saint-Andre, E. Marocco.

Date: November 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7081

This document suggests some strategies for the combined use of theSession Initiation Protocol (SIP) and the Extensible Messaging andPresence Protocol (XMPP) both in user-oriented clients and in deployed servers. Such strategies, which mainly consist of configuration changes and minimal software modifications to existing clients and servers, aim to provide a single, full-featured, real- time communication service by using complementary subsets of features from SIP and from XMPP. Typically, such subsets consist of telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This document does not define any new protocols or syntax for either SIP or XMPP and, by intent, does not attempt to standardize "best current practices". Instead, it merely aims to provide practical guidance to those who are interested in the combined use of SIP and XMPP for real-time communication.

RFC 7082 Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP)

Authors: R. Shekh-Yusef, M. Barnes.

Date: December 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7082

The Centralized Conferencing Manipulation Protocol (CCMP) document(RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for theCentralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference.
This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the "purpose" header field parameter in the<service-uris&rt; element in the SIP conferencing event package.

RFC 7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT

Authors: R. Droms.

Date: November 2013

Formats: txt json html

Obsoleted by: RFC 8415

Updates: RFC 3315

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7083

This document updates RFC 3315 by redefining the default values forSOL_MAX_RT and INF_MAX_RT and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT andINF_MAX_RT with new values.

RFC 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 7085 Top-Level Domains That Are Already Dotless

Authors: J. Levine, P. Hoffman.

Date: December 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7085

Recent statements from the Internet Architecture Board (IAB) and theInternet Corporation of Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee have focused on the problems that the DNS is likely to experience with top-level domains (TLDs) that contain address records (so-called "dotless domains"). In order to help researchers determine the extent of the issues with dotless domains, this document lists the current dotless TLDs and gives a script for finding them. This document lists data about dotless TLDs but does not address the policy and technology issues other than to point to the statements of others.

RFC 7086 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)

Authors: A. Keranen, G. Camarillo, J. Maenpaa.

Date: January 2014

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7086

This document is the HIP-Based Overlay Networking Environment (HIPBONE) instance specification for the REsource LOcation And Discovery(RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP.

RFC 7087 A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations

Authors: H. van Helvoort, Ed., L. Andersson, Ed., N. Sprecher, Ed..

Date: December 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7087

The MPLS Transport Profile (MPLS-TP) is based on a profile of theMPLS and Pseudowire (PW) procedures as specified in the MPLS TrafficEngineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force(IETF). The International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) has specified a Transport Network architecture.
This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport NetworkRecommendations.
It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive or complete interpretations ofMPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context.

RFC 7088 Session Initiation Protocol Service Example -- Music on Hold

Authors: D. Worley.

Date: February 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7088

"Music on hold" is one of the features of telephone systems that is most desired by buyers of business telephone systems. Music on hold means that when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards- compliant. The implementation of music on hold described in this document is fully effective, is standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems that perform authentication than the music- on-hold method described in Section 2.3 of RFC 5359.

RFC 7089 HTTP Framework for Time-Based Access to Resource States -- Memento

Authors: H. Van de Sompel, M. Nelson, R. Sanderson.

Date: December 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7089

The HTTP-based Memento framework bridges the present and past Web.It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.

RFC 7090 Public Safety Answering Point (PSAP) Callback

Authors: H. Schulzrinne, H. Tschofenig, C. Holmberg, M. Patel.

Date: April 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7090

After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim.A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine.
The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. We describe a solution based on a new header field value for the SIP Priority header field, called "psap-callback", to markPSAP callbacks.

RFC 7091 GOST R 34.10-2012: Digital Signature Algorithm

Authors: V. Dolmatov, Ed., A. Degtyarev.

Date: December 2013

Formats: txt html json

Updates: RFC 5832

Status: INFORMATIONAL

DOI: 10.17487/RFC 7091

This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of theRussian cryptographic standard algorithms (called GOST algorithms).Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification. This document updates RFC 5832.

RFC 7092 A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents

Authors: H. Kaplan, V. Pascual.

Date: December 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7092

In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server(UAS) and User Agent Client (UAC).
There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs),Session Border Controllers (SBCs), and Application Servers (ASs).This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.

RFC 7093 Additional Methods for Generating Key Identifiers Values

Authors: S. Turner, S. Kent, J. Manger.

Date: December 2013

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7093

This document specifies additional example methods for generating KeyIdentifier values for use in the AKI (Authority Key Identifier) andSKI (Subject Key Identifier) certificate extensions.

RFC 7094 Architectural Considerations of IP Anycast

Authors: D. McPherson, D. Oran, D. Thaler, E. Osterweil.

Date: January 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7094

This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.

RFC 7095 jCard: The JSON Format for vCard

Authors: P. Kewisch.

Date: January 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7095

This specification defines "jCard", a JSON format for vCard data.The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.

RFC 7096 Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)

Authors: S. Belotti, Ed., P. Grandi, D. Ceccarelli, Ed., D. Caviglia, F. Zhang, D. Li.

Date: January 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7096

ITU-T recommendation G.709-2012 has introduced new fixed and flexibleOptical channel Data Unit (ODU) containers in Optical TransportNetworks (OTNs).
This document provides an evaluation of existing GeneralizedMultiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs.

RFC 7097 RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets

Authors: J. Ott, V. Singh, Ed., I. Curcio.

Date: January 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7097

The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in order to provide a variety of short- term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the de- jitter buffer after successful reception.

RFC 7098 Using the IPv6 Flow Label for Load Balancing in Server Farms

Authors: B. Carpenter, S. Jiang, W. Tarreau.

Date: January 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7098

This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms.

RFC 7100 Retirement of the "Internet Official Protocol Standards" Summary Document

Authors: P. Resnick.

Date: December 2013

Formats: txt html json

Obsoletes: RFC 5000

Updates: RFC 2026

Also: BCP 0009

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7100

This document updates RFC 2026 to no longer use STD 1 as a summary of"Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.

RFC 7101 List of Internet Official Protocol Standards: Replaced by a Web Page

Authors: S. Ginoza.

Date: December 2013

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7101

At one time, the RFC Editor published snapshots of the "InternetOfficial Protocol Standards". These documents were known as xx00 documents, the last of which was published in May 2008. These snapshots have been replaced by a web page, so the RFC Editor will no longer be publishing these snapshots as RFCs. As a result, the RFCEditor will classify unpublished RFC xx00 numbers through 7000 as never issued. Starting with the RFC number 7100, xx00 numbers will be available for assignment.

RFC 7102 Terms Used in Routing for Low-Power and Lossy Networks

Authors: JP. Vasseur.

Date: January 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7102

This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power andLossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.

RFC 7103 Advice for Safe Handling of Malformed Messages

Authors: M. Kucherawy, G. Shapiro, N. Freed.

Date: January 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7103

Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance.

RFC 7104 Duplication Grouping Semantics in the Session Description Protocol

Authors: A. Begen, Y. Cai, H. Ou.

Date: January 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7104

Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP).The semantics defined in this document are to be used with the SDPGrouping Framework. Grouping semantics at the Synchronization Source(SSRC) level are also defined in this document for RTP streams usingSSRC multiplexing.

RFC 7105 Using Device-Provided Location-Related Measurements in Location Configuration Protocols

Authors: M. Thomson, J. Winterbottom.

Date: January 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7105

This document describes a protocol for a Device to provide location- related measurement data to a Location Information Server (LIS) within a request for location information. Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment. A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global NavigationSatellite System (GNSS) parameters.

RFC 7106 A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State

Authors: E. Ivov.

Date: January 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7106

This document defines and registers a value of "grouptextchat"("Group Text Chat") for the URI <purpose&rt; element of SIP's ConferenceEvent Package.

RFC 7107 Object Identifier Registry for the S/MIME Mail Security Working Group

Authors: R. Housley.

Date: January 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7107

When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group. This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc toIANA, and establishes IANA allocation policies for any future assignments within that arc.

RFC 7108 A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes

Authors: J. Abley, T. Manderson.

Date: January 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7108

Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion.
Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed.Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency.
This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service.

RFC 7109 Flow Bindings Initiated by Home Agents for Mobile IPv6

Authors: H. Yokota, D. Kim, B. Sarikaya, F. Xia.

Date: February 2014

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7109

There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node, such as moving a flow from one access network to another based on network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Flow bindings initiated by a home agent are supported for mobile nodes enabled by both IPv4 and IPv6.

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 7111 URI Fragment Identifiers for the text/csv Media Type

Authors: M. Hausenblas, E. Wilde, J. Tennison.

Date: January 2014

Formats: txt html json

Updates: RFC 4180

Status: INFORMATIONAL

DOI: 10.17487/RFC 7111

This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity identified by row, column, or cell.Fragment identification can use single items or ranges.

RFC 7112 Implications of Oversized IPv6 Header Chains

Authors: F. Gont, V. Manral, R. Bonica.

Date: January 2014

Formats: txt json html

Updates: RFC 2460

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7112

The IPv6 specification allows IPv6 Header Chains of an arbitrary size. The specification also allows options that can, in turn, extend each of the headers. In those scenarios in which the IPv6Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6Header Chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that theFirst Fragment of a packet is required to contain the entire IPv6Header Chain.

RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)

Authors: F. Gont.

Date: February 2014

Formats: txt json html

Updates: RFC 6105

Status: INFORMATIONAL

DOI: 10.17487/RFC 7113

The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 RouterAdvertisement messages. Many existing IPv6 deployments rely onRA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 ExtensionHeaders. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.

RFC 7114 Creation of a Registry for smime-type Parameter Values

Authors: B. Leiba.

Date: January 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7114

Secure/Multipurpose Internet Mail Extensions (S/MIME) defined theContent-Type parameter "smime-type". As the list of defined values for that parameter has increased, it has become clear that a registry is needed to document these values. This document creates the registry, registers the current values, and specifies the policies for registration of new values.

RFC 7115 Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)

Authors: R. Bush.

Date: January 2014

Formats: txt html json

Also: BCP 0185

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7115

Deployment of BGP origin validation that is based on the ResourcePublic Key Infrastructure (RPKI) has many operational considerations.This document attempts to collect and present those that are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood.

RFC 7116 Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries

Authors: K. Scott, M. Blanchet.

Date: February 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7116

The DTNRG Research Group has defined the experimental LickliderTransmission Protocol (LTP) and the Compressed Bundle Header Encoding(CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme).Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields are subject to a registry. For the purpose of its research work, the group has created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the necessary IANA actions.

RFC 7117 Multicast in Virtual Private LAN Service (VPLS)

Authors: R. Aggarwal, Ed., Y. Kamite, L. Fang, Y. Rekhter, C. Kodeboniya.

Date: February 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7117

RFCs 4761 and 4762 describe a solution for Virtual Private LANService (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certainVPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported.
This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multipleVPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances.

RFC 7118 The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)

Authors: I. Baz Castillo, J. Millan Villegas, V. Pascual.

Date: January 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7118

The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications. This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use ofSIP in web-oriented deployments.

RFC 7119 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators

Authors: B. Claise, A. Kobayashi, B. Trammell.

Date: February 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7119

This document specifies the operation of the IP Flow InformationExport (IPFIX) protocol specific to IPFIX Mediators, includingTemplate and Observation Point management, timing considerations, and other Mediator-specific concerns.

RFC 7120 Early IANA Allocation of Standards Track Code Points

Authors: M. Cotton.

Date: January 2014

Formats: txt html json

Obsoletes: RFC 4020

Also: BCP 0100

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7120

This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFCRequired", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.
This document obsoletes RFC 4020.

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 7122 Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)

Authors: H. Kruse, S. Jero, S. Ostermann.

Date: March 2014

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7122

This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over theInternet using datagrams. It covers convergence layers for theBundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of theDelay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.

RFC 7123 Security Implications of IPv6 on IPv4 Networks

Authors: F. Gont, W. Liu.

Date: February 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7123

This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues.

RFC 7124 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

Authors: E. Beili.

Date: February 2014

Formats: txt html json

Updates: RFC 5066

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7124

This document updates RFC 5066. It amends that specification by informing the Internet community about the transition of theEFM-CU-MIB module from the concluded IETF Ethernet Interfaces and HubMIB Working Group to the Institute of Electrical and ElectronicsEngineers (IEEE) 802.3 working group.

RFC 7125 Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element

Authors: B. Trammell, P. Aitken.

Date: February 2014

Formats: txt html json

Obsoleted by: RFC 9565

Status: INFORMATIONAL

DOI: 10.17487/RFC 7125

This document revises the tcpControlBits IP Flow Information Export(IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.

RFC 7126 Recommendations on Filtering of IPv4 Packets Containing IPv4 Options

Authors: F. Gont, R. Atkinson, C. Pignataro.

Date: February 2014

Formats: txt json html

Also: BCP 0186

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7126

This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.

RFC 7127 Characterization of Proposed Standards

Authors: O. Kolkman, S. Bradner, S. Turner.

Date: January 2014

Formats: txt json html

Updates: RFC 2026

Also: BCP 0009

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7127

RFC 2026 describes the review performed by the Internet EngineeringSteering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.

RFC 7128 Resource Public Key Infrastructure (RPKI) Router Implementation Report

Authors: R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch.

Date: February 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7128

This document is an implementation report for the Resource Public KeyInfrastructure (RPKI) Router protocol as defined in RFC 6810. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab.

RFC 7129 Authenticated Denial of Existence in the DNS

Authors: R. Gieben, W. Mekking.

Date: February 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7129

Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record(RR) type you were asking for. When returning a negative DNSSecurity Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.
This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses.

RFC 7130 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces

Authors: M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed..

Date: February 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7130

This document defines a mechanism to run Bidirectional ForwardingDetection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on everyLAG member link.
This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link AggregationControl Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements ofLayer 3 (L3) bidirectional forwarding.

RFC 7131 Session Initiation Protocol (SIP) History-Info Header Call Flow Examples

Authors: M. Barnes, F. Audet, S. Schubert, H. van Elburg, C. Holmberg.

Date: March 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7131

This document describes use cases and documents call flows that require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details.

RFC 7132 Threat Model for BGP Path Security

Authors: S. Kent, A. Chi.

Date: February 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7132

This document describes a threat model for the context in whichExternal Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the ResourcePublic Key Infrastructure (RPKI) and focuses on the ability of anAutonomous System (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term "PATHSEC" to refer to anyBGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of theRPKI.
The document characterizes classes of potential adversaries that are considered to be threats and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in theBGP-4 standard. It concludes with a brief discussion of residual vulnerabilities.

RFC 7133 Information Elements for Data Link Layer Traffic Measurement

Authors: S. Kashima, A. Kobayashi, Ed., P. Aitken.

Date: May 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7133

This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.

RFC 7134 The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review"

Authors: B. Rosen.

Date: March 2014

Formats: txt html json

Updates: RFC 4412

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7134

RFC 4412 defines the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updatesRFC 4412 to change the management policy of these registries to "IETFReview".

RFC 7135 Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications

Authors: J. Polk.

Date: May 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7135

This document creates the new Session Initiation Protocol (SIP)Resource Priority header field namespace 'esnet' and registers this namespace with IANA. The new header field namespace allows for local emergency session establishment to a public safety answering point(PSAP), between PSAPs, and between a PSAP and first responders and their organizations.

RFC 7136 Significance of IPv6 Interface Identifiers

Authors: B. Carpenter, S. Jiang.

Date: February 2014

Formats: txt json html

Updates: RFC 4291

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7136

The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses.Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which theUniversal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updatesRFC 4291 accordingly.

RFC 7137 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks

Authors: A. Retana, S. Ratliff.

Date: February 2014

Formats: txt json html

Updates: RFC 5820

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7137

This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature.
This document updates RFC 5820.

RFC 7138 Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks

Authors: D. Ceccarelli, Ed., F. Zhang, S. Belotti, R. Rao, J. Drake.

Date: March 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7138

This document describes Open Shortest Path First - TrafficEngineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-TRecommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203.

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 7141 Byte and Packet Congestion Notification

Authors: B. Briscoe, J. Manner.

Date: February 2014

Formats: txt json html

Updates: RFC 2309, RFC 2914

Also: BCP 0041

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7141

This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre-Congestion Notification (PCN), and newer schemes such as CoDel(Controlled Delay) and PIE (Proportional Integral controllerEnhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte- mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms.

RFC 7142 Reclassification of RFC 1142 to Historic

Authors: M. Shand, L. Ginsberg.

Date: February 2014

Formats: txt html json

Obsoletes: RFC 1142

Status: INFORMATIONAL

DOI: 10.17487/RFC 7142

This memo reclassifies RFC 1142, "OSI IS-IS Intra-domain RoutingProtocol", to Historic status. This memo also obsoletes RFC 1142.

RFC 7143 Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)

Authors: M. Chadalapaka, J. Satran, K. Meth, D. Black.

Date: April 2014

Formats: txt html json

Obsoletes: RFC 3720, RFC 3980, RFC 4850, RFC 5048

Updates: RFC 3721

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7143

This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to the iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications as well as a few improvements and corrections to the original iSCSI protocol.
This document obsoletes RFCs 3720, 3980, 4850, and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics.

RFC 7144 Internet Small Computer System Interface (iSCSI) SCSI Features Update

Authors: F. Knight, M. Chadalapaka.

Date: April 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7144

Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols ontoTCP/IP. The iSCSI protocol as specified in RFC 7143 (and as previously specified by the combination of RFC 3720 and RFC5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined inSAM-3, SAM-4, and SAM-5.
This document is a companion document to RFC 7143.

RFC 7145 Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification

Authors: M. Ko, A. Nezhinsky.

Date: April 2014

Formats: txt json html

Obsoletes: RFC 5046

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7145

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. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/OBuffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol.
This document obsoletes RFC 5046.

RFC 7146 Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3

Authors: D. Black, P. Koning.

Date: April 2014

Formats: txt html json

Updates: RFC 3720, RFC 3723, RFC 3821, RFC 3822, RFC 4018, RFC 4172, RFC 4173, RFC 4174, RFC 5040, RFC 5041, RFC 5042, RFC 5043, RFC 5044, RFC 5045, RFC 5046, RFC 5047, RFC 5048

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7146

RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP).This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published.

RFC 7147 Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI)

Authors: M. Bakke, P. Venkatesen.

Date: April 2014

Formats: txt html json

Obsoletes: RFC 4544

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7147

This document defines a portion of the Management Information Base(MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet SmallComputer System Interface (iSCSI) protocol (SCSI over TCP).
This document obsoletes RFC 4544.

RFC 7148 Prefix Delegation Support for Proxy Mobile IPv6

Authors: X. Zhou, J. Korhonen, C. Williams, S. Gundavelli, CJ. Bernardos.

Date: March 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7148

This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes.

RFC 7149 Software-Defined Networking: A Perspective from within a Service Provider Environment

Authors: M. Boucadair, C. Jacquenet.

Date: March 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7149

Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.
It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.

RFC 7150 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol

Authors: F. Zhang, A. Farrel.

Date: March 2014

Formats: txt json html

Obsoleted by: RFC 7470

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7150

The Path Computation Element communication Protocol (PCEP) is used to convey path computation requests and responses both between PathComputation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.
This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object.

RFC 7151 File Transfer Protocol HOST Command for Virtual Hosts

Authors: P. Hethmon, R. McMurray.

Date: March 2014

Formats: txt json html

Updates: RFC 0959

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7151

The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.

RFC 7152 Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN)

Authors: R. Key, Ed., S. DeLord, F. Jounay, L. Huang, Z. Liu, M. Paul.

Date: March 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7152

This document provides functional requirements for the support ofMetro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer2 Virtual Private Network solutions (referred to as simply "L2VPN").It is intended that potential solutions will use these requirements as guidelines.

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 7154 IETF Guidelines for Conduct

Authors: S. Moonesamy, Ed..

Date: March 2014

Formats: txt json html

Obsoletes: RFC 3184

Also: BCP 0054

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7154

This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.
This document is an updated version of the guidelines for conduct originally published in RFC 3184.

RFC 7155 Diameter Network Access Server Application

Authors: G. Zorn, Ed..

Date: April 2014

Formats: txt json html

Obsoletes: RFC 4005

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7155

This document describes the Diameter protocol application used forAuthentication, Authorization, and Accounting services in the NetworkAccess Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, andExtensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.

RFC 7156 Diameter Support for Proxy Mobile IPv6 Localized Routing

Authors: G. Zorn, Q. Wu, J. Korhonen.

Date: April 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7156

In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by theMobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term"localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node(CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol.

RFC 7157 IPv6 Multihoming without Network Address Translation

Authors: O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing.

Date: March 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7157

Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because anIPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. ForIPv6 hosts, one approach could be the use of IPv6-to-IPv6 NetworkPrefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution.

RFC 7158 The JavaScript Object Notation (JSON) Data Interchange Format

Authors: T. Bray, Ed..

Date: March 2014

Formats: txt json html

Obsoleted by: RFC 7159

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7158

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance.

RFC 7159 The JavaScript Object Notation (JSON) Data Interchange Format

Authors: T. Bray, Ed..

Date: March 2014

Formats: txt json html

Obsoletes: RFC 4627, RFC 7158

Obsoleted by: RFC 8259

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7159

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance.

RFC 7160 Support for Multiple Clock Rates in an RTP Session

Authors: M. Petit-Huguenin, G. Zorn, Ed..

Date: April 2014

Formats: txt json html

Updates: RFC 3550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7160

This document clarifies the RTP specification regarding the use of different clock rates in an RTP session. It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document. It updates RFC 3550.

RFC 7161 Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)

Authors: LM. Contreras, CJ. Bernardos, I. Soto.

Date: March 2014

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7161

This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers.The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem.Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router).

RFC 7162 IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)

Authors: A. Melnikov, D. Cridland.

Date: May 2014

Formats: txt html json

Obsoletes: RFC 4551, RFC 5162

Updates: RFC 2683

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7162

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox.
Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state.This memo updates that mechanism and obsoletes RFC 4551, based on operational experience.
This document additionally updates another IMAP extension, QuickResynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162.
Finally, this document also updates the line-length recommendation inSection 3.2.1.5 of RFC 2683.

RFC 7163 URN for Country-Specific Emergency Services

Authors: C. Holmberg, I. Sedlacek.

Date: March 2014

Formats: txt html json

Updates: RFC 5031

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7163

This document updates the registration guidance provided in Section4.2 of RFC 5031, which allows the registration of service URNs with the 'sos' service type only for emergency services "that are offered widely and in different countries". This document updates those instructions to allow such registrations when, at the time of registration, those services are offered in only one country.

RFC 7164 RTP and Leap Seconds

Authors: K. Gross, R. Brandenburg.

Date: March 2014

Formats: txt json html

Updates: RFC 3550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7164

This document discusses issues that arise when RTP sessions spanCoordinated Universal Time (UTC) leap seconds. It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds.

RFC 7165 Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)

Authors: R. Barnes.

Date: April 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7165

Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. For many years, the Cryptographic Message Syntax(CMS) has provided a binary secure object format based on ASN.1.Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript ObjectNotation (JSON). This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development.

RFC 7166 Supporting Authentication Trailer for OSPFv3

Authors: M. Bhatia, V. Manral, A. Lindem.

Date: March 2014

Formats: txt html json

Obsoletes: RFC 6506

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7166

Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2,Intermediate System to Intermediate System (IS-IS), RIP, and RoutingInformation Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.
The OSPFv3 Authentication Trailer was originally defined in RFC 6506.This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.

RFC 7167 A Framework for Point-to-Multipoint MPLS in Transport Networks

Authors: D. Frost, S. Bryant, M. Bocci, L. Berger.

Date: April 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7167

The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths.This document defines the elements and functions of the MPLS-TP architecture that are applicable specifically to supporting point-to- multipoint transport paths.

RFC 7168 The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)

Authors: I. Nazar.

Date: 1 April 2014

Formats: txt json html

Updates: RFC 2324

Status: INFORMATIONAL

DOI: 10.17487/RFC 7168

The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.

RFC 7169 The NSA (No Secrecy Afforded) Certificate Extension

Authors: S. Turner.

Date: 1 April 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7169

This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic KeyCertificates) digital certificates. Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained. In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party.Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party.

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 7171 PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods

Authors: N. Cam-Winget, P. Sangster.

Date: May 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7171

This document specifies PT-EAP, a Posture Transport (PT) protocol based on the Extensible Authentication Protocol (EAP) and designed to be used only inside an EAP tunnel method protected by Transport LayerSecurity (TLS). The document also describes the intended applicability of PT-EAP.

RFC 7172 Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling

Authors: D. Eastlake 3rd, M. Zhang, P. Agarwal, R. Perlman, D. Dutt.

Date: May 2014

Formats: txt html json

Updates: RFC 6325

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7172

The IETF has standardized Transparent Interconnection of Lots ofLinks (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4KIDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine- grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.

RFC 7173 Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires

Authors: L. Yong, D. Eastlake 3rd, S. Aldrin, J. Hudson.

Date: May 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7173

This document specifies how to interconnect a pair of TransparentInterconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End(PWE3) standards.

RFC 7174 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework

Authors: S. Salam, T. Senevirathne, S. Aldrin, D. Eastlake 3rd.

Date: May 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7174

This document specifies a reference framework for Operations,Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks. The focus of the document is on the fault and performance management aspects of TRILL OAM.

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 7176 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS

Authors: D. Eastlake 3rd, T. Senevirathne, A. Ghanwani, D. Dutt, A. Banerjee.

Date: May 2014

Formats: txt html json

Obsoletes: RFC 6326

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7176

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other thanTRILL. This document obsoletes RFC 6326.

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 7180 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates

Authors: D. Eastlake 3rd, M. Zhang, A. Ghanwani, V. Manral, A. Banerjee.

Date: May 2014

Formats: txt json html

Obsoleted by: RFC 7780

Updates: RFC 6325, RFC 6327, RFC 6439

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7180

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic.TRILL accomplishes this by using Intermediate System to IntermediateSystem (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.
RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439.

RFC 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 7182 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)

Authors: U. Herberg, T. Clausen, C. Dearlove.

Date: April 2014

Formats: txt html json

Obsoletes: RFC 6622

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7182

This document revises, extends, and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic IntegrityCheck Values (ICVs) and timestamps, using the generalized Mobile AdHoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively.

RFC 7183 Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)

Authors: U. Herberg, C. Dearlove, T. Clausen.

Date: April 2014

Formats: txt html json

Updates: RFC 6130, RFC 7181

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7183

This document specifies integrity and replay protection for theMobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2).This protection is achieved by using an HMAC-SHA-256 Integrity CheckValue (ICV) TLV and a Timestamp TLV based on Portable OperatingSystem Interface (POSIX) time.
The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described inRFC 5444.
This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP andOLSRv2.

RFC 7184 Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2

Authors: U. Herberg, R. Cole, T. Clausen.

Date: April 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7184

This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State RoutingProtocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into configuration information, state information, performance information, and notifications. This additional state and performance information is useful for troubleshooting problems and performance issues of the routing protocol. Two levels of compliance allow this MIB module to be deployed on constrained routers.

RFC 7185 Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale

Authors: C. Dearlove, T. Clausen, P. Jacquet.

Date: April 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7185

The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.

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 7187 Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2)

Authors: C. Dearlove, T. Clausen.

Date: April 2014

Formats: txt html json

Updates: RFC 7181

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7187

This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing multipoint relays. The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization.

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 7189 Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP)

Authors: G. Mirsky.

Date: March 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7189

This document specifies how signaling and selection processes forPseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) are modified to ensure backward compatibility and allow use of proactiveConnectivity Verification (CV), Continuity Check (CC), and RemoteDefect Indication (RDI) over MPLS Transport Profile (MPLS-TP) PWs.This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined.

RFC 7190 Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)

Authors: C. Villamizar.

Date: March 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7190

Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TPOperations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.
Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths(LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP.The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.

RFC 7191 Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types

Authors: R. Housley.

Date: April 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7191

This document defines the syntax for two Cryptographic Message Syntax(CMS) content types: one for key package receipts and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.

RFC 7192 Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types

Authors: S. Turner.

Date: April 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7192

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData,EnvelopedData, EncryptedData, and AuthEnvelopedData.

RFC 7193 The application/cms Media Type

Authors: S. Turner, R. Housley, J. Schaad.

Date: April 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7193

This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types.

RFC 7194 Default Port for Internet Relay Chat (IRC) via TLS/SSL

Authors: R. Hartmann.

Date: August 2014

Formats: txt json html

Updates: RFC 1459

Status: INFORMATIONAL

DOI: 10.17487/RFC 7194

This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL.

RFC 7195 Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)

Authors: M. Garcia-Martin, S. Veikkolainen.

Date: May 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7195

This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN).

RFC 7196 Making Route Flap Damping Usable

Authors: C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. Maennel.

Date: May 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7196

Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process.

RFC 7197 Duplication Delay Attribute in the Session Description Protocol

Authors: A. Begen, Y. Cai, H. Ou.

Date: April 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7197

A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply"delayed duplication". This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol.

RFC 7198 Duplicating RTP Streams

Authors: A. Begen, C. Perkins.

Date: April 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7198

Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains howReal-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules.

RFC 7199 Location Configuration Extensions for Policy Management

Authors: R. Barnes, M. Thomson, J. Winterbottom, H. Tschofenig.

Date: April 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7199

Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules.

RFC 7200 A Session Initiation Protocol (SIP) Load-Control Event Package

Authors: C. Shen, H. Schulzrinne, A. Koike.

Date: April 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7200

This specification defines a load-control event package for theSession Initiation Protocol (SIP). It allows SIP entities to distribute load-filtering policies to other SIP entities in the network. The load-filtering policies contain rules to throttle calls from a specific user or based on their source or destination domain, telephone number prefix. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts.

RFC 7201 Options for Securing RTP Sessions

Authors: M. Westerlund, C. Perkins.

Date: April 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7201

The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.

RFC 7202 Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution

Authors: C. Perkins, M. Westerlund.

Date: April 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7202

This memo discusses the problem of securing real-time multimedia sessions. It also explains why the Real-time Transport Protocol(RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism. This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture.

RFC 7203 An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information

Authors: T. Takahashi, K. Landfield, Y. Kadobayashi.

Date: April 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7203

This document extends the Incident Object Description Exchange Format(IODEF) defined in RFC 5070 to exchange enriched cybersecurity information among security experts at organizations and facilitate their operations. It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information.

RFC 7204 Requirements for Labeled NFS

Authors: T. Haynes.

Date: April 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7204

This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into theNetwork File System (NFS) version 4.2 (NFSv4.2). It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. The intent here is not to present the protocol changes but to describe the environment in which they reside.

RFC 7205 Use Cases for Telepresence Multistreams

Authors: A. Romanow, S. Botzko, M. Duckworth, R. Even, Ed..

Date: April 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7205

Telepresence conferencing systems seek to create an environment that gives users (or user groups) that are not co-located a feeling of co- located presence through multimedia communication that includes at least audio and video signals of high fidelity. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would enable senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference.

RFC 7206 Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks

Authors: P. Jones, G. Salgueiro, J. Polk, L. Liess, H. Kaplan.

Date: May 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7206

This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.

RFC 7207 A Uniform Resource Name (URN) Namespace for Eurosystem Messaging

Authors: M. Ortseifen, G. Dickfeld.

Date: April 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7207

This document defines and registers with IANA a Uniform Resource Name(URN) namespace for usage within messages standardized by theEurosystem. The URN namespace is managed by Deutsche Bundesbank, which is a member of the European System of Central Banks (ESCB).

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 7209 Requirements for Ethernet VPN (EVPN)

Authors: A. Sajassi, R. Aggarwal, J. Uttaro, N. Bitar, W. Henderickx, A. Isaac.

Date: May 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7209

The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverageMultipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto- discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues.

RFC 7210 Database of Long-Lived Symmetric Cryptographic Keys

Authors: R. Housley, T. Polk, S. Hartman, D. Zhang.

Date: April 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7210

This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database.In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key.

RFC 7211 Operations Model for Router Keying

Authors: S. Hartman, D. Zhang.

Date: June 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7211

The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed inRFC 6518, "Keying and Authentication for Routing Protocols (KARP)Design Guidelines". Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts.This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face.

RFC 7212 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol

Authors: D. Frost, S. Bryant, M. Bocci.

Date: June 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7212

The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations,Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes.

RFC 7213 MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing

Authors: D. Frost, S. Bryant, M. Bocci.

Date: June 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7213

The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets.

RFC 7214 Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry

Authors: L. Andersson, C. Pignataro.

Date: May 2014

Formats: txt json html

Updates: RFC 5586, RFC 6374, RFC 6378, RFC 6427, RFC 6428

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7214

RFC 5586 generalized the applicability of the pseudowire AssociatedChannel Header (PW-ACH) into the Generic Associated Channel G-ACh.However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries.This document coalesces these into a new "Generic Associated Channel(G-ACh) Parameters" registry under the "Multiprotocol Label SwitchingArchitecture (MPLS)" heading. This document updates RFC 5586.
This document also updates RFCs 6374, 6378, 6427, and 6428.

RFC 7215 Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations

Authors: L. Jakab, A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual, D. Lewis.

Date: April 2014

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7215

This document is a snapshot of different Locator/IdentifierSeparation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.

RFC 7216 Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS

Authors: M. Thomson, R. Bellis.

Date: April 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7216

The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location InformationServer (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway.
This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device.

RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)

Authors: F. Gont.

Date: April 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7217

This document specifies a method for generating IPv6 InterfaceIdentifiers to be used with IPv6 Stateless Address Autoconfiguration(SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control(MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes(and their corresponding addresses).

RFC 7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)

Authors: O. Gudmundsson.

Date: April 2014

Formats: txt json html

Updates: RFC 6698

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7218

Experience has shown that people get confused when discussing the three numeric fields of the TLSA record. This document specifies descriptive acronyms for the three numeric fields in TLSA records.This document updates the format of the IANA registry created by RFC6698.

RFC 7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)

Authors: M. Bagnulo, A. Garcia-Martinez.

Date: May 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7219

This memo specifies SEcure Neighbor Discovery (SEND) Source AddressValidation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses.

RFC 7220 Description Option for the Port Control Protocol (PCP)

Authors: M. Boucadair, R. Penno, D. Wing.

Date: May 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7220

This document extends the Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping.It does this by defining a new DESCRIPTION option.

RFC 7221 Handling of Internet-Drafts by IETF Working Groups

Authors: A. Farrel, D. Crocker, Ed..

Date: April 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7221

The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication.

RFC 7222 Quality-of-Service Option for Proxy Mobile IPv6

Authors: M. Liebsch, P. Seite, H. Yokota, J. Korhonen, S. Gundavelli.

Date: May 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7222

This specification defines a new mobility option, the Quality-of-Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality-of-Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway.Furthermore, making QoS parameters available on the mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access-technology-specific approaches.

RFC 7223 A YANG Data Model for Interface Management

Authors: M. Bjorklund.

Date: May 2014

Formats: txt html json

Obsoleted by: RFC 8343

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7223

This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document.The data model includes configuration data and state data (status information and counters for the collection of statistics).

RFC 7224 IANA Interface Type YANG Module

Authors: M. Bjorklund.

Date: May 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7224

This document defines the initial version of the iana-if-type YANG module.

RFC 7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)

Authors: M. Boucadair.

Date: May 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7225

This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals.

RFC 7226 Requirements for Advanced Multipath in MPLS Networks

Authors: C. Villamizar, Ed., D. McDysan, Ed., S. Ning, A. Malis, L. Yong.

Date: May 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7226

This document provides a set of requirements for Advanced Multipath in MPLS networks.
Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques.

RFC 7227 Guidelines for Creating New DHCPv6 Options

Authors: D. Hankins, T. Mrugalski, M. Siodelski, S. Jiang, S. Krishnan.

Date: May 2014

Formats: txt html json

Updates: RFC 3315

Also: BCP 0187

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7227

This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315.

RFC 7228 Terminology for Constrained-Node Networks

Authors: C. Bormann, M. Ersue, A. Keranen.

Date: May 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7228

The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.

RFC 7229 Object Identifiers for Test Certificate Policies

Authors: R. Housley.

Date: May 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7229

This document provides several certificate policy identifiers for testing certificate handling software.

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 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

Authors: R. Fielding, Ed., J. Reschke, Ed..

Date: June 2014

Formats: txt json html

Obsoletes: RFC 2616

Obsoleted by: RFC 9110

Updates: RFC 2817

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7231

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.

RFC 7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests

Authors: R. Fielding, Ed., J. Reschke, Ed..

Date: June 2014

Formats: txt html json

Obsoletes: RFC 2616

Obsoleted by: RFC 9110

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7232

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.

RFC 7233 Hypertext Transfer Protocol (HTTP/1.1): Range Requests

Authors: R. Fielding, Ed., Y. Lafon, Ed., J. Reschke, Ed..

Date: June 2014

Formats: txt html json

Obsoletes: RFC 2616

Obsoleted by: RFC 9110

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7233

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.

RFC 7234 Hypertext Transfer Protocol (HTTP/1.1): Caching

Authors: R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed..

Date: June 2014

Formats: txt json html

Obsoletes: RFC 2616

Obsoleted by: RFC 9111

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7234

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.

RFC 7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication

Authors: R. Fielding, Ed., J. Reschke, Ed..

Date: June 2014

Formats: txt json html

Obsoletes: RFC 2616, RFC 2617

Obsoleted by: RFC 9110

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7235

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.

RFC 7236 Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations

Authors: J. Reschke.

Date: June 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7236

This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANAHTTP Authentication Scheme Registry was established.

RFC 7237 Initial Hypertext Transfer Protocol (HTTP) Method Registrations

Authors: J. Reschke.

Date: June 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7237

This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP MethodRegistry was established.

RFC 7238 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)

Authors: J. Reschke.

Date: June 2014

Formats: txt json html

Obsoleted by: RFC 7538

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7238

This document specifies the additional Hypertext Transfer Protocol(HTTP) status code 308 (Permanent Redirect).

RFC 7239 Forwarded HTTP Extension

Authors: A. Petersson, M. Nilsson.

Date: June 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7239

This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.
This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.

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 7242 Delay-Tolerant Networking TCP Convergence-Layer Protocol

Authors: M. Demmer, J. Ott, S. Perreault.

Date: June 2014

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7242

This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of theIRTF's DTN Research Group (DTNRG).

RFC 7243 RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric

Authors: V. Singh, Ed., J. Ott, I. Curcio.

Date: May 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7243

The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a report computing the bytes discarded from the de-jitter buffer after successful reception.

RFC 7244 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting

Authors: H. Asaeda, Q. Wu, R. Huang.

Date: May 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7244

This document defines two RTP Control Protocol (RTCP) Extended Report(XR) blocks that allow the reporting of initial synchronization delay and synchronization offset metrics for use in a range of RTP applications.

RFC 7245 An Architecture for Media Recording Using the Session Initiation Protocol

Authors: A. Hutton, Ed., L. Portman, Ed., R. Jain, K. Rehor.

Date: May 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7245

Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment that is based on the Session Initiation Protocol (SIP).

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 7247 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling

Authors: P. Saint-Andre, A. Houri, J. Hildebrand.

Date: May 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7247

As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the ExtensibleMessaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.

RFC 7248 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence

Authors: P. Saint-Andre, A. Houri, J. Hildebrand.

Date: May 2014

Formats: txt html json

Obsoleted by: RFC 8048

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7248

This document defines a bidirectional protocol mapping for the exchange of presence information between the Session InitiationProtocol (SIP) and the Extensible Messaging and Presence Protocol(XMPP).

RFC 7249 Internet Numbers Registries

Authors: R. Housley.

Date: May 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7249

RFC 7020 provides information about the Internet Numbers RegistrySystem and how it is used in the distribution of autonomous system(AS) numbers and globally unique unicast Internet Protocol (IP) address space.
This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time.

RFC 7250 Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

Authors: P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen.

Date: June 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7250

This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) andDatagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.

RFC 7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS

Authors: D. McGrew, D. Bailey, M. Campagna, R. Dugal.

Date: June 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7251

This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within TransportLayer Security (TLS) to provide confidentiality and data-origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security. The cipher suites defined in this document use Elliptic CurveCryptography (ECC) and are advantageous in networks with limited bandwidth.

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 7253 The OCB Authenticated-Encryption Algorithm

Authors: T. Krovetz, P. Rogaway.

Date: May 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7253

This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG).

RFC 7254 A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)

Authors: M. Montemurro, Ed., A. Allen, D. McDonald, P. Gosden.

Date: May 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7254

This specification defines a Uniform Resource Name (URN) namespace for the Global System for Mobile Communications Association (GSMA) and a Namespace Specific String (NSS) for the International Mobile station Equipment Identity (IMEI), as well as an associated parameter for the International Mobile station Equipment Identity and SoftwareVersion number (IMEISV). The IMEI and IMEISV were introduced as part of the specification for the GSM and are also now incorporated by the3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, Universal Mobile Telecommunications System(UMTS), and 3GPP Long Term Evolution (LTE) networks. The IMEI andIMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA. URNs from this namespace almost always contain personally identifiable information and need to be treated accordingly.

RFC 7255 Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID

Authors: A. Allen, Ed..

Date: May 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7255

This specification defines how the Uniform Resource Name (URN) reserved for the Global System for Mobile Communications Association(GSMA) identities and its sub-namespace for the International Mobile station Equipment Identity (IMEI) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specificURN needs to be constructed and used in the '+sip.instance' Contact header field parameter for outbound behavior.

RFC 7256 Multicast Control Extensions for the Access Node Control Protocol (ANCP)

Authors: F. Le Faucheur, R. Maglione, T. Taylor.

Date: July 2014

Formats: txt json html

Updates: RFC 6320

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7256

This document specifies the extensions to the Access Node ControlProtocol (ANCP) (RFC 6320) required for support of the multicast use cases defined in the Access Node Control Protocol framework document(RFC 5851) and one additional use case described in this document.These use cases are organized into the following ANCP capabilities: o multicast replication initiated by the Network Access Server(NAS); o conditional access and admission control with white and black lists; o conditional access and admission control with grey lists; o bandwidth delegation; and o committed bandwidth reporting.
These capabilities may be combined according to the rules given in this specification.
This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETFConsensus from 0x100 to 0x64.

RFC 7257 Virtual Private LAN Service (VPLS) Management Information Base

Authors: T. Nadeau, Ed., A. Kiran Koushik, Ed., R. Mediratta, Ed..

Date: July 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7257

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 to configure and/or monitor Virtual Private LAN services. It needs to be used in conjunction with the Pseudowire (PW) Management Information Base(PW-STD-MIB from RFC 5601).

RFC 7258 Pervasive Monitoring Is an Attack

Authors: S. Farrell, H. Tschofenig.

Date: May 2014

Formats: txt html json

Also: BCP 0188

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7258

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

RFC 7259 The Jabber-ID Header Field

Authors: P. Saint-Andre.

Date: May 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7259

This document defines a header field that enables the author of an email or netnews message to include a Jabber ID in the message header block for the purpose of associating the author with a particularExtensible Messaging and Presence Protocol (XMPP) address.

RFC 7260 GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration

Authors: A. Takacs, D. Fedyk, J. He.

Date: June 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7260

Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configureOAM entities. This document specifies extensions to ResourceReservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with LabelSwitched Path signaling.

RFC 7261 Offer/Answer Considerations for G723 Annex A and G729 Annex B

Authors: M. Perumal, P. Ravindran.

Date: May 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7261

This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D, and G729E when the value of the annexa or annexb parameter does not match in the Session Description Protocol (SDP) offer and answer.

RFC 7262 Requirements for Telepresence Multistreams

Authors: A. Romanow, S. Botzko, M. Barnes.

Date: June 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7262

This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein.

RFC 7263 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing

Authors: N. Zong, X. Jiang, R. Even, Y. Zhang.

Date: June 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7263

This document defines an optional extension to the REsource LOcationAnd Discovery (RELOAD) protocol to support the direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers.This document also describes potential cases where this extension can be used.

RFC 7264 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing

Authors: N. Zong, X. Jiang, R. Even, Y. Zhang.

Date: June 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7264

This document defines an optional extension to the REsource LOcationAnd Discovery (RELOAD) protocol to support the relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used.

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 7266 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting

Authors: A. Clark, Q. Wu, R. Schott, G. Zorn.

Date: June 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7266

This document defines an RTP Control Protocol (RTCP) Extended Report(XR) Block including two new segment types and associated SessionDescription Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications.

RFC 7267 Dynamic Placement of Multi-Segment Pseudowires

Authors: L. Martini, Ed., M. Bocci, Ed., F. Balus, Ed..

Date: June 2014

Formats: txt json html

Updates: RFC 6073

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7267

RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet SwitchedNetwork domains. A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi- segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.

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 7269 NAT64 Deployment Options and Experience

Authors: G. Chen, Z. Cao, C. Xie, D. Binet.

Date: June 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7269

This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) andNAT64 server Front End (NAT64-FE) are considered in this document.

RFC 7270 Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)

Authors: A. Yourtchenko, P. Aitken, B. Claise.

Date: June 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7270

This document describes some additional IP Flow Information Export(IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC3954, as specified in the IPFIX Information Model in RFC 7012.

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 7272 Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)

Authors: R. van Brandenburg, H. Stokking, O. van Deventer, F. Boronat, M. Montagud, K. Gross.

Date: June 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7272

This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achievingInter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using theRTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS SettingsPacket can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize.
Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc.

RFC 7273 RTP Clock Source Signalling

Authors: A. Williams, K. Gross, R. van Brandenburg, H. Stokking.

Date: June 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7273

NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifiesSession Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session.

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 7275 Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy

Authors: L. Martini, S. Salam, A. Sajassi, M. Bocci, S. Matsushima, T. Nadeau.

Date: June 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7275

This document specifies an Inter-Chassis Communication Protocol(ICCP) that enables Provider Edge (PE) device redundancy for VirtualPrivate Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a Redundancy Group, for the purpose of synchronizing data among the systems. It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms.

RFC 7276 An Overview of Operations, Administration, and Maintenance (OAM) Tools

Authors: T. Mizrahi, N. Sprecher, E. Bellagamba, Y. Weingarten.

Date: June 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7276

Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack.
This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links(TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document.Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.
The target audience of this document includes network equipment vendors, network operators, and standards development organizations.This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary.

RFC 7277 A YANG Data Model for IP Management

Authors: M. Bjorklund.

Date: June 2014

Formats: txt json html

Obsoleted by: RFC 8344

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7277

This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data.

RFC 7278 Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link

Authors: C. Byrne, D. Drown, A. Vizdal.

Date: June 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7278

This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples.

RFC 7279 An Acceptable Use Policy for New ICMP Types and Codes

Authors: M. Shore, C. Pignataro.

Date: May 2014

Formats: txt html json

Also: BCP 0189

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7279

In this document we provide a basic description of ICMP's role in theIP stack and some guidelines for future use.
This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not.

RFC 7280 IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry

Authors: G. Fairhurst.

Date: June 2014

Formats: txt html json

Updates: RFC 4326

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7280

This document updates RFC 4326 to clarify and update the allocation rules for the Unidirectional Lightweight Encapsulation (ULE) Next-Header registry. This registry is used by ULE and Generic StreamEncapsulation (GSE) to record the code points of Extension Headers and protocols supported by these encapsulation protocols.

RFC 7281 Authentication-Results Registration for S/MIME Signature Verification

Authors: A. Melnikov.

Date: June 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7281

RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication-Results header field for S/MIME-related signature checks.

RFC 7282 On Consensus and Humming in the IETF

Authors: P. Resnick.

Date: June 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7282

The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views amongIETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.
Note: This document is quite consciously being put forward asInformational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus.

RFC 7283 Handling Unknown DHCPv6 Messages

Authors: Y. Cui, Q. Sun, T. Lemon.

Date: July 2014

Formats: txt json html

Obsoleted by: RFC 8415

Updates: RFC 3315

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7283

DHCPv6 is not specific about handling messages with unknown types.This memo describes the problems associated with receiving DHCPv6 messages with unknown types, and defines how a DHCPv6 server, client, or relay agent should behave when receiving unknown DHCPv6 messages.This document also provides advice for authors of future documents that define new messages to be sent from DHCP servers to DHCP relay agents. This document updates RFC 3315.

RFC 7284 The Profile URI Registry

Authors: M. Lanthaler.

Date: June 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7284

This document defines a registry for profile URIs to be used in specifications standardizing profiles.

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 7286 Application-Layer Traffic Optimization (ALTO) Server Discovery

Authors: S. Kiesel, M. Stiemerling, N. Schwan, M. Scharf, H. Song.

Date: November 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7286

The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before anALTO client can ask for guidance, it needs to discover one or moreALTO servers.
This document specifies a procedure for resource-consumer-initiatedALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer.

RFC 7287 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains

Authors: T. Schmidt, Ed., S. Gao, H. Zhang, M. Waehlisch.

Date: June 2014

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7287

Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying MulticastListener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios.Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations.

RFC 7288 Reflections on Host Firewalls

Authors: D. Thaler.

Date: June 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7288

In today's Internet, the need for firewalls is generally accepted in the industry, and indeed firewalls are widely deployed in practice.Unlike traditional firewalls that protect network links, host firewalls run in end-user systems. Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a host firewall. It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication. In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward.

RFC 7289 Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs

Authors: V. Kuarsingh, Ed., J. Cianfarani.

Date: June 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7289

This document specifies a framework to integrate a Network AddressTranslation (NAT) layer into an operator's network to function as aCarrier-Grade NAT (also known as CGN or Large-Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber-side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near- term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model that allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IPVPNs, which allow for virtual routing separation, helping ease theCGN's impact on the network. This document does not intend to defend the merits of CGN.

RFC 7290 Test Plan and Results for Advancing RFC 2680 on the Standards Track

Authors: L. Ciavattone, R. Geib, A. Morton, M. Wieser.

Date: July 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7290

This memo provides the supporting test plan and results to advanceRFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2680.

RFC 7291 DHCP Options for the Port Control Protocol (PCP)

Authors: M. Boucadair, R. Penno, D. Wing.

Date: July 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7291

This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document.

RFC 7292 PKCS #12: Personal Information Exchange Syntax v1.1

Authors: K. Moriarty, Ed., M. Nystrom, S. Parkinson, A. Rusch, M. Scott.

Date: July 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7292

PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.
This document represents a republication of PKCS #12 v1.1 from RSALaboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

RFC 7293 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension

Authors: W. Mills, M. Kucherawy.

Date: July 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7293

This document defines an extension for the Simple Mail TransferProtocol (SMTP) called "RRVS" to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This document also defines a header field called "Require-Recipient-Valid-Since" that can be used to tunnel the request through servers that do not support the extension.
The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications.

RFC 7294 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications

Authors: A. Clark, G. Zorn, C. Bi, Q. Wu.

Date: July 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7294

This document defines two RTP Control Protocol (RTCP) Extended Report(XR) blocks that allow the reporting of concealment metrics for audio applications of RTP.

RFC 7295 Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication

Authors: H. Tschofenig, L. Eggert, Z. Sarker.

Date: July 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7295

This document provides a summary of the IAB/IRTF Workshop on'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the InternetEngineering Task Force (IETF) community.
The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or theInternet Research Task Force (IRTF).

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 7297 IP Connectivity Provisioning Profile (CPP)

Authors: M. Boucadair, C. Jacquenet, N. Wang.

Date: July 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7297

This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP.
Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives ofTraffic Engineering functions and service management functions, and(3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs.

RFC 7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication

Authors: D. Ovsienko.

Date: July 2014

Formats: txt html json

Obsoleted by: RFC 8967

Updates: RFC 6126

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7298

This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.

RFC 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 7300 Reservation of Last Autonomous System (AS) Numbers

Authors: J. Haas, J. Mitchell.

Date: July 2014

Formats: txt html json

Updates: RFC 1930

Also: BCP 0006

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7300

This document reserves two Autonomous System Numbers (ASNs) at the end of the 16-bit and 32-bit ranges, described in this document as"Last ASNs", and provides guidance to implementers and operators on their use. This document updates Section 10 of RFC 1930.

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 7302 Entertainment Identifier Registry (EIDR) URN Namespace Definition

Authors: P. Lemieux.

Date: July 2014

Formats: txt json html

Obsoleted by: RFC 7972

Status: INFORMATIONAL

DOI: 10.17487/RFC 7302

Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name(URN) Namespace Identifier (NID) for EIDR Identifiers.

RFC 7303 XML Media Types

Authors: H. Thompson, C. Lilley.

Date: July 2014

Formats: txt json html

Obsoletes: RFC 3023

Updates: RFC 6839

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7303

This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to theExtensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities.

RFC 7304 A Method for Mitigating Namespace Collisions

Authors: W. Kumari.

Date: July 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7304

This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict.

RFC 7305 Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)

Authors: E. Lear, Ed..

Date: July 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7305

This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on Internet Technology Adoption andTransition (ITAT). The workshop was hosted by the University ofCambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass (e.g., the middle of the protocol stack). This report summarizes contributions and discussions. As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time.Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 7306 Remote Direct Memory Access (RDMA) Protocol Extensions

Authors: H. Shah, F. Marti, W. Noureddine, A. Eiriksson, R. Sharp.

Date: June 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7306

This document specifies extensions to the IETF Remote Direct MemoryAccess Protocol (RDMAP) as specified in RFC 5040. 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. The extensions specified in this document provide the following capabilities and/or improvements:Atomic Operations and Immediate Data.

RFC 7307 LDP Extensions for Multi-Topology

Authors: Q. Zhao, K. Raza, C. Zhou, L. Fang, L. Li, D. King.

Date: July 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7307

Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing withinMultiprotocol Label Switching (MPLS) Label Distribution Protocol(LDP) networks, new extensions are required.
This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.

RFC 7308 Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)

Authors: E. Osborne.

Date: July 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7308

MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using theAdministrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630),OSPFv3 (RFC 5329) and IS-IS (RFC 5305).
This document adds a sub-TLV to the IGP TE extensions, "ExtendedAdministrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.

RFC 7309 Redundancy Mechanism for Inter-domain VPLS Service

Authors: Z. Liu, L. Jin, R. Chen, D. Cai, S. Salam.

Date: July 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7309

In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy with only a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domainVPLS solution that provides PE node redundancy across domains.

RFC 7310 RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs

Authors: J. Lindsay, H. Foerster.

Date: July 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7310

This document specifies a scheme for packetizing Standard apt-X orEnhanced apt-X encoded audio data into Real-time Transport Protocol(RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP).

RFC 7311 The Accumulated IGP Metric Attribute for BGP

Authors: P. Mohapatra, R. Fernando, E. Rosen, J. Uttaro.

Date: August 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7311

Routing protocols that have been designed to run within a single administrative domain (IGPs) generally do so by assigning a metric to each link and then choosing, as the installed path between two nodes, the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains (autonomous systems), does not make its path-selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems as well as inter- administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so.

RFC 7312 Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)

Authors: J. Fabini, A. Morton.

Date: August 2014

Formats: txt json html

Updates: RFC 2330

Status: INFORMATIONAL

DOI: 10.17487/RFC 7312

To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates theIP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.

RFC 7313 Enhanced Route Refresh Capability for BGP-4

Authors: K. Patel, E. Chen, B. Venkatachalapathy.

Date: July 2014

Formats: txt json html

Updates: RFC 2918

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7313

In this document, we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner. This document updates RFC 2918.

RFC 7314 Extension Mechanisms for DNS (EDNS) EXPIRE Option

Authors: M. Andrews.

Date: July 2014

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7314

This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries.

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 7316 The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header)

Authors: J. van Elburg, K. Drage, M. Ohsugi, S. Schubert, K. Arai.

Date: July 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7316

This document specifies the SIP P-Private-Network-Indication P-header used by the 3GPP. The P-Private-Network-Indication indicates that the message is part of the message traffic of a private network and identifies that private network. A private network indication allows nodes to treat private network traffic according to a different set of rules than the set applicable to public network traffic.

RFC 7317 A YANG Data Model for System Management

Authors: A. Bierman, M. Bjorklund.

Date: August 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7317

This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.

RFC 7318 Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates

Authors: A. Newton, G. Huston.

Date: July 2014

Formats: txt html json

Updates: RFC 6487

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7318

This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of Resource PublicKey Infrastructure (RPKI) resource certificates.

RFC 7319 IANA Considerations for Connectivity Fault Management (CFM) Code Points

Authors: D. Eastlake 3rd.

Date: July 2014

Formats: txt html json

Also: BCP 0191

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7319

IEEE 802.1 has specified Connectivity Fault Management (CFM)Operations, Administration, and Maintenance (OAM) facilities. CFM messages are structured with an OpCode field and have provision for the inclusion of TLV-structured information. IEEE 802.1 has allocated blocks of CFM OpCodes and TLV Types to the IETF. This document specifies the IANA considerations for the assignment of values from these blocks.

RFC 7320 URI Design and Ownership

Authors: M. Nottingham.

Date: July 2014

Formats: txt html json

Obsoleted by: RFC 8820

Updates: RFC 3986

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7320

Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards.

RFC 7321 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)

Authors: D. McGrew, P. Hoffman.

Date: August 2014

Formats: txt html json

Obsoletes: RFC 4835

Obsoleted by: RFC 8221

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7321

This document updates the Cryptographic Algorithm ImplementationRequirements for the Encapsulating Security Payload (ESP) andAuthentication Header (AH). It also adds usage guidance to help in the selection of these algorithms.
ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.
This document obsoletes RFC 4835.

RFC 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 7323 TCP Extensions for High Performance

Authors: D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed..

Date: September 2014

Formats: txt json html

Obsoletes: RFC 1323

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7323

This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against WrappedSequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.
This document obsoletes RFC 1323 and describes changes from it.

RFC 7324 Updates to MPLS Transport Profile Linear Protection

Authors: E. Osborne.

Date: July 2014

Formats: txt html json

Updates: RFC 6378

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7324

This document contains a number of updates to the Protection StateCoordination (PSC) logic defined in RFC 6378, "MPLS Transport Profile(MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC 6378.

RFC 7325 MPLS Forwarding Compliance and Performance Requirements

Authors: C. Villamizar, Ed., K. Kompella, S. Amante, A. Malis, C. Pignataro.

Date: August 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7325

This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations.Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements that are unstated or underemphasized, or that are optional for conformance to RFCs but often considered mandatory by providers.

RFC 7326 Energy Management Framework

Authors: J. Parello, B. Claise, B. Schoening, J. Quittek.

Date: September 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7326

This document defines a framework for Energy Management (EMAN) for devices and device components within, or connected to, communication networks. The framework presents a physical reference model and information model. The information model consists of an EnergyManagement Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. EnergyObjects can be monitored and controlled with respect to power, PowerState, energy, demand, Power Attributes, and battery. Additionally, the framework models relationships and capabilities between EnergyObjects.

RFC 7328 Writing I-Ds and RFCs Using Pandoc and a Bit of XML

Authors: R. Gieben.

Date: August 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7328

This document presents a technique for using a Markdown syntax variant, called Pandoc, and a bit of XML (as defined in RFC 2629) as a source format for documents that are Internet-Drafts (I-Ds) orRFCs.
The goal of this technique (which is called Pandoc2rfc) is to let an author of an I-D focus on the main body of text without being distracted too much by XML tags; however, it does not alleviate the need to typeset some files in XML.

RFC 7329 A Session Identifier for the Session Initiation Protocol (SIP)

Authors: H. Kaplan.

Date: August 2014

Formats: txt html json

Obsoleted by: RFC 7989

Status: INFORMATIONAL

DOI: 10.17487/RFC 7329

There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIPProxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID.
The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a newStandards Track document produced by the INSIPID Working Group.

RFC 7330 Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management

Authors: T. Nadeau, Z. Ali, N. Akiya.

Date: August 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7330

This document defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly usedBidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD-related MIB modules that would otherwise define their own representations.

RFC 7331 Bidirectional Forwarding Detection (BFD) Management Information Base

Authors: T. Nadeau, Z. Ali, N. Akiya.

Date: August 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7331

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Bidirectional Forwarding Detection (BFD) protocol.

RFC 7332 Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)

Authors: H. Kaplan, V. Pascual.

Date: August 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7332

SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs and the requirements for them to prevent infinite loops.

RFC 7333 Requirements for Distributed Mobility Management

Authors: H. Chan, Ed., D. Liu, P. Seite, H. Yokota, J. Korhonen.

Date: August 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7333

This document defines the requirements for Distributed MobilityManagement (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described.

RFC 7334 PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths

Authors: Q. Zhao, D. Dhody, D. King, Z. Ali, R. Casellas.

Date: August 2014

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7334

The ability to compute paths for constrained point-to-multipoint(P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks.The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths ofP2MP TE LSPs.
This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.

RFC 7335 IPv4 Service Continuity Prefix

Authors: C. Byrne.

Date: August 2014

Formats: txt html json

Updates: RFC 6333

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7335

Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element.Per this memo, IANA has generalized that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution.

RFC 7336 Framework for Content Distribution Network Interconnection (CDNI)

Authors: L. Peterson, B. Davie, R. van Brandenburg, Ed..

Date: August 2014

Formats: txt json html

Obsoletes: RFC 3466

Status: INFORMATIONAL

DOI: 10.17487/RFC 7336

This document presents a framework for Content Distribution NetworkInterconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnectCDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletesRFC 3466.

RFC 7337 Content Distribution Network Interconnection (CDNI) Requirements

Authors: K. Leung, Ed., Y. Lee, Ed..

Date: August 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7337

Content delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existingCDN providers are scaling up their infrastructure. Many NetworkService Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the ContentService Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users.
The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group.

RFC 7338 Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks

Authors: F. Jounay, Ed., Y. Kamite, Ed., G. Heron, M. Bocci.

Date: September 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7338

This document presents a set of requirements and a framework for providing a point-to-multipoint pseudowire (PW) over MPLS PacketSwitched Networks. The requirements identified in this document are related to architecture, signaling, and maintenance aspects of point- to-multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, point-to-multipoint PWs can be used to optimize the support of multicast Layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service).

RFC 7339 Session Initiation Protocol (SIP) Overload Control

Authors: V. Gurbani, Ed., V. Hilt, H. Schulzrinne.

Date: September 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7339

Overload occurs in Session Initiation Protocol (SIP) networks whenSIP servers have insufficient resources to handle all the SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (ServiceUnavailable) response code, SIP servers are still vulnerable to overload. This document defines the behavior of SIP servers involved in overload control and also specifies a loss-based overload scheme for SIP.

RFC 7340 Secure Telephone Identity Problem Statement and Requirements

Authors: J. Peterson, H. Schulzrinne, H. Tschofenig.

Date: September 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7340

Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.

RFC 7341 DHCPv4-over-DHCPv6 (DHCP 4o6) Transport

Authors: Q. Sun, Y. Cui, M. Siodelski, S. Krishnan, I. Farrer.

Date: August 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7341

IPv4 connectivity is still needed as networks migrate towards IPv6.Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose.

RFC 7342 Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers

Authors: L. Dunbar, W. Kumari, I. Gashinsky.

Date: August 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7342

This memo documents some operational practices that allow ARP andNeighbor Discovery (ND) to scale in data center environments.

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 7346 IPv6 Multicast Address Scopes

Authors: R. Droms.

Date: August 2014

Formats: txt html json

Updates: RFC 4007, RFC 4291

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7346

This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291.

RFC 7347 Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP)

Authors: H. van Helvoort, Ed., J. Ryoo, Ed., H. Zhang, F. Huang, H. Li, A. D'Alessandro.

Date: September 2014

Formats: txt html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7347

The IETF Standards Track solution for MPLS Transport Profile(MPLS-TP) Linear Protection is provided in RFCs 6378, 7271, and 7324.
This document describes the pre-standard implementation of MPLS-TPLinear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication, these pre-standard implementations were still in operation carrying live traffic.
The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by the MPLS-TP data plane and can work without any control plane.

RFC 7348 Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks

Authors: M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright.

Date: August 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7348

This document describes Virtual eXtensible Local Area Network(VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.

RFC 7349 LDP Hello Cryptographic Authentication

Authors: L. Zheng, M. Chen, M. Bhatia.

Date: August 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7349

This document introduces a new optional Cryptographic AuthenticationTLV that LDP can use to secure its Hello messages. It secures theHello messages against spoofing attacks and some well-known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code(HMAC) with the National Institute of Standards and Technology (NIST)Secure Hash Standard family of algorithms.

RFC 7350 Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)

Authors: M. Petit-Huguenin, G. Salgueiro.

Date: August 2014

Formats: txt json html

Updates: RFC 5389, RFC 5928

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7350

This document specifies the usage of Datagram Transport LayerSecurity (DTLS) as a transport protocol for Session TraversalUtilities for NAT (STUN). It provides guidance on when and how to use DTLS with the currently standardized STUN usages. It also specifies modifications to the STUN and Traversal Using Relay NAT(TURN) URIs and to the TURN resolution mechanism to facilitate the resolution of STUN and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. This document updates RFCs 5389 and 5928.

RFC 7351 A Media Type for XML Patch Operations

Authors: E. Wilde.

Date: August 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7351

The XML patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document. The XML patch document format builds on the foundations defined in RFC 5261. This specification also provides the media type registration "application/xml-patch+xml", to allow the use of XML patch documents in, for example, HTTP conversations.

RFC 7352 Sieve Email Filtering: Detecting Duplicate Deliveries

Authors: S. Bosch.

Date: September 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7352

This document defines a new test command, "duplicate", for the Sieve email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the"duplicate" test can also use the content of a specific header field or other parts of the message.

RFC 7353 Security Requirements for BGP Path Validation

Authors: S. Bellovin, R. Bush, D. Ward.

Date: August 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7353

This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AutonomousSystem (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement.

RFC 7354 Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace

Authors: A. Adolf, P. Siebert.

Date: September 2014

Formats: txt json html

Updates: RFC 5328

Status: INFORMATIONAL

DOI: 10.17487/RFC 7354

RFC 5328 registered the Uniform Resource Name (URN) namespace "dvb" for the Digital Video Broadcasting Project. This document updatesRFC 5328 with new registrant information.

RFC 7355 Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF)

Authors: G. Salgueiro, V. Pascual, A. Roman, S. Garcia.

Date: September 2014

Formats: txt json html

Updates: RFC 6873

Status: INFORMATIONAL

DOI: 10.17487/RFC 7355

RFC 7118 specifies a WebSocket subprotocol as a reliable real-time transport mechanism between Session Initiation Protocol (SIP) entities to enable usage of SIP in web-oriented deployments. This document updates the SIP Common Log Format (CLF), defined in RFC6873, with a new "Transport Flag" for such SIP WebSocket transport.

RFC 7356 IS-IS Flooding Scope Link State PDUs (LSPs)

Authors: L. Ginsberg, S. Previdi, Y. Yang.

Date: September 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7356

Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units(PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length.
The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.

RFC 7357 Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol

Authors: H. Zhai, F. Hu, R. Perlman, D. Eastlake 3rd, O. Stokes.

Date: September 2014

Formats: txt html json

Updates: RFC 6325

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7357

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 topologies and link technologies. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL switches or RBridges (Routing Bridges).
ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label(VLAN or fine-grained label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible.

RFC 7358 Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)

Authors: K. Raza, S. Boutros, L. Martini, N. Leymann.

Date: October 2014

Formats: txt json html

Updates: RFC 3212, RFC 4447, RFC 5036, RFC 5918, RFC 6388, RFC 7140

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7358

The label advertising behavior of an LDP speaker for a givenForwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear. It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types.

RFC 7359 Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks

Authors: F. Gont.

Date: August 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7359

The subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue.

RFC 7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS

Authors: A. DeKok.

Date: September 2014

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7360

The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport LayerSecurity (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems.

RFC 7361 LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)

Authors: P. Dutta, F. Balus, O. Stokes, G. Calvignac, D. Fedyk.

Date: September 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7361

RFC 4762 describes a mechanism to remove or unlearn Media AccessControl (MAC) addresses that have been dynamically learned in aVirtual Private LAN Service (VPLS) instance for faster convergence on topology changes. The procedure also removes MAC addresses in theVPLS that do not require relearning due to such topology changes.This document defines an enhancement to the MAC address withdraw procedure with an empty MAC list (RFC 4762); this enhancement enables a Provider Edge (PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to RFC 4762 MAC withdraw procedures are specified to provide an optimized MAC flushing for theProvider Backbone Bridging (PBB) VPLS specified in RFC 7041.

RFC 7362 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication

Authors: E. Ivov, H. Kaplan, D. Wing.

Date: September 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7362

This document describes the behavior of signaling intermediaries inReal-Time Communication (RTC) deployments, sometimes referred to asSession Border Controllers (SBCs), when performing Hosted NATTraversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other.
This document is non-normative and is only written to explain HNT in order to provide a reference to the Internet community and an informative description to manufacturers and users.
Latching, which is one of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of the latching mechanism over the Internet and recommends other solutions, such as the InteractiveConnectivity Establishment (ICE) protocol.

RFC 7363 Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)

Authors: J. Maenpaa, G. Camarillo.

Date: September 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7363

REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size.

RFC 7364 Problem Statement: Overlays for Network Virtualization

Authors: T. Narten, Ed., E. Gray, Ed., D. Black, L. Fang, L. Kreeger, M. Napierala.

Date: October 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7364

This document describes issues associated with providing multi- tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach. A key multi-tenancy requirement is traffic isolation so that one tenant's traffic is not visible to any other tenant. Another requirement is address space isolation so that different tenants can use the same address space within different virtual networks.Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway).Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network and maintaining that association as the virtual machine is activated, migrated, and/or deactivated. Use of an overlay-based approach enables scalable deployment on large network infrastructures.

RFC 7365 Framework for Data Center (DC) Network Virtualization

Authors: M. Lasserre, F. Balus, T. Morin, N. Bitar, Y. Rekhter.

Date: October 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7365

This document provides a framework for Data Center (DC) NetworkVirtualization over Layer 3 (NVO3) and defines a reference model along with logical components required to design a solution.

RFC 7366 Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

Authors: P. Gutmann.

Date: September 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7366

This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC- then-encrypt mechanism in Transport Layer Security (TLS) and DatagramTransport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.

RFC 7367 Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process

Authors: R. Cole, J. Macker, B. Adamson.

Date: October 2014

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7367

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects for configuring aspects of theSimplified Multicast Forwarding (SMF) process for Mobile Ad HocNetworks (MANETs). The SMF-MIB module also reports state information, performance information, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems.

RFC 7368 IPv6 Home Networking Architecture Principles

Authors: T. Chown, Ed., J. Arkko, A. Brandt, O. Troan, J. Weil.

Date: October 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7368

This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network.

RFC 7369 GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration

Authors: A. Takacs, B. Gero, H. Long.

Date: October 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7369

The work related to GMPLS Ethernet Label Switching (GELS) extendedGMPLS RSVP-TE to support the establishment of Ethernet LabelSwitching Paths (LSPs). IEEE Ethernet Connectivity Fault Management(CFM) specifies an adjunct Operations, Administration, andMaintenance (OAM) flow to check connectivity in Ethernet networks.CFM can also be used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, includingPerformance Monitoring, for Ethernet networks. This document specifies extensions of the GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs and defines the Ethernet technology-specific TLVs based on the GMPLS OAMConfiguration Framework. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms.

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 7371 Updates to the IPv6 Multicast Addressing Architecture

Authors: M. Boucadair, S. Venaas.

Date: September 2014

Formats: txt json html

Updates: RFC 3306, RFC 3956, RFC 4291

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7371

This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits.
This document updates RFCs 3956, 3306, and 4291.

RFC 7372 Email Authentication Status Codes

Authors: M. Kucherawy.

Date: September 2014

Formats: txt html json

Updates: RFC 7208

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7372

This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures.
This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document.

RFC 7373 Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types

Authors: B. Trammell.

Date: September 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7373

This document defines UTF-8 representations for IP Flow InformationExport (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings.

RFC 7374 Service Discovery Usage for REsource LOcation And Discovery (RELOAD)

Authors: J. Maenpaa, G. Camarillo.

Date: October 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7374

REsource LOcation And Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol (RFC6940). This document defines how the Recursive DistributedRendezvous (ReDiR) service discovery mechanism can be applied toRELOAD overlays to provide a generic service discovery mechanism.

RFC 7375 Secure Telephone Identity Threat Model

Authors: J. Peterson.

Date: October 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7375

As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched.

RFC 7376 Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN)

Authors: T. Reddy, R. Ravindranath, M. Perumal, A. Yegin.

Date: September 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7376

This document discusses some of the security problems and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages.

RFC 7377 IMAP4 Multimailbox SEARCH Extension

Authors: B. Leiba, A. Melnikov.

Date: October 2014

Formats: txt html json

Obsoletes: RFC 6237

Updates: RFC 4466

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7377

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT andSEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses.This document updates RFC 4466 and obsoletes RFC 6237.

RFC 7378 Trustworthy Location

Authors: H. Tschofenig, H. Schulzrinne, B. Aboba, Ed..

Date: December 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7378

The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance.
This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information.

RFC 7379 Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge

Authors: Y. Li, W. Hao, R. Perlman, J. Hudson, H. Zhai.

Date: October 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7379

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active connection at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus. This informational document discusses the high-level problems and goals when providing active- active connection at the TRILL edge.

RFC 7380 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting

Authors: J. Tong, C. Bi, Ed., R. Even, Q. Wu, Ed., R. Huang.

Date: November 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7380

An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/multicastMPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR block are related to Program Specific Information(PSI) carried in MPEG TS.

RFC 7381 Enterprise IPv6 Deployment Guidelines

Authors: K. Chittimaneni, T. Chown, L. Howard, V. Kuarsingh, Y. Pouffary, E. Vyncke.

Date: October 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7381

Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually anIPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.

RFC 7382 Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)

Authors: S. Kent, D. Kong, K. Seo.

Date: April 2015

Formats: txt html json

Also: BCP 0173

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7382

This document contains a template to be used for creating aCertification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP.

RFC 7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation

Authors: V. Smyslov.

Date: November 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7383

This document describes a way to avoid IP fragmentation of largeInternet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allowIP fragments to pass through.

RFC 7384 Security Requirements of Time Protocols in Packet Switched Networks

Authors: T. Mizrahi.

Date: October 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7384

As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on thePrecision Time Protocol (PTP) and the Network Time Protocol (NTP).This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.

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 7386 JSON Merge Patch

Authors: P. Hoffman, J. Snell.

Date: October 2014

Formats: txt html json

Obsoleted by: RFC 7396

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7386

This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with theHTTP PATCH method as a means of describing a set of modifications to a target resource's content.

RFC 7387 A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network

Authors: R. Key, Ed., L. Yong, Ed., S. Delord, F. Jounay, L. Jin.

Date: October 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7387

This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over aMultiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network.

RFC 7388 Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

Authors: J. Schoenwaelder, A. Sehgal, T. Tsou, C. Zhou.

Date: October 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7388

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IPv6 overLow-Power Wireless Personal Area Networks (6LoWPANs).

RFC 7389 Separation of Control and User Plane for Proxy Mobile IPv6

Authors: R. Wakikawa, R. Pazhyannur, S. Gundavelli, C. Perkins.

Date: October 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7389

This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy MobileIPv6 (PMIPv6). Existing specifications allow a mobile access gateway(MAG) to separate its control and user plane using the AlternateCare-of Address mobility option for IPv6 or Alternate IPv4 Care-ofAddress option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA. With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane.

RFC 7390 Group Communication for the Constrained Application Protocol (CoAP)

Authors: A. Rahman, Ed., E. Dijk, Ed..

Date: October 2014

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7390

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks.It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group).This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies.

RFC 7391 Forwarding and Control Element Separation (ForCES) Protocol Extensions

Authors: J. Hadi Salim.

Date: October 2014

Formats: txt json html

Updates: RFC 5810, RFC 7121

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7391

Experience in implementing and deploying the Forwarding and ControlElement Separation (ForCES) architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. The ForCES protocol is extended with a table range operation and a new extension for error handling. This document updates the semantics in RFCs 5810 and 7121 to achieve that end goal.

RFC 7392 Explicit Path Routing for Dynamic Multi-Segment Pseudowires

Authors: P. Dutta, M. Bocci, L. Martini.

Date: December 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7392

When set up through an explicit path, dynamic Multi-SegmentPseudowires (MS-PWs) may be required to provide a simple solution for1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths.

RFC 7393 Using the Port Control Protocol (PCP) to Update Dynamic DNS

Authors: X. Deng, M. Boucadair, Q. Zhao, J. Huang, C. Zhou.

Date: November 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7393

This document focuses on the problems encountered when using dynamicDNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) andNetwork Address and Protocol Translation from IPv6 Clients to IPv4Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo.

RFC 7394 Definition of Time to Live TLV for LSP-Ping Mechanisms

Authors: S. Boutros, S. Sivabalan, G. Swallow, S. Saxena, V. Manral, S. Aldrin.

Date: November 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7394

LSP-Ping is a widely deployed Operation, Administration, andMaintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment Pseudowire (MS-PW) and/or bidirectional co-routed Label Switched Path (LSP) from any node on the path of theMS-PW and/or bidirectional co-routed LSP. This document defines aTLV to address this shortcoming.

RFC 7395 An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket

Authors: L. Stout, Ed., J. Moffitt, E. Cestari.

Date: October 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7395

This document defines a binding for the Extensible Messaging andPresence Protocol (XMPP) over a WebSocket transport layer. AWebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP.

RFC 7396 JSON Merge Patch

Authors: P. Hoffman, J. Snell.

Date: October 2014

Formats: txt html json

Obsoletes: RFC 7386

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7396

This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with theHTTP PATCH method as a means of describing a set of modifications to a target resource's content.

RFC 7397 Report from the Smart Object Security Workshop

Authors: J. Gilger, H. Tschofenig.

Date: December 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7397

This document provides a summary of a workshop on 'Smart ObjectSecurity' that took place in Paris on March 23, 2012. The main goal of the workshop was to allow participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects.
This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

RFC 7398 A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance

Authors: M. Bagnulo, T. Burbridge, S. Crawford, P. Eardley, A. Morton.

Date: February 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7398

This document defines a reference path for Large-scale Measurement ofBroadband Access Performance (LMAP) and measurement points for commonly used performance metrics. Other similar measurement projects may also be able to use the extensions described here for measurement point location. The purpose is to create an efficient way to describe the location of the measurement point(s) used to conduct a particular measurement.

RFC 7399 Unanswered Questions in the Path Computation Element Architecture

Authors: A. Farrel, D. King.

Date: October 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7399

The Path Computation Element (PCE) architecture is set out in RFC4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) inRFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.
These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.
This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.

RFC 7400 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

Authors: C. Bormann.

Date: November 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7400

RFC 6282 defines header compression in 6LoWPAN packets (where"6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal AreaNetwork"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload.

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 7402 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)

Authors: P. Jokela, R. Moskowitz, J. Melen.

Date: April 2015

Formats: txt html json

Obsoletes: RFC 5202

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7402

This memo specifies an Encapsulating Security Payload (ESP) based mechanism for transmission of user data packets, to be used with theHost Identity Protocol (HIP). This document obsoletes RFC 5202.

RFC 7403 A Media-Based Traceroute Function for the Session Initiation Protocol (SIP)

Authors: H. Kaplan.

Date: November 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7403

SIP already provides the ability to perform hop-by-hop traceroute forSIP messages using the Max-Forwards header field to determine the reachability path of requests to a target. A mechanism for media- loopback calls has also been defined separately, which enables test calls to be generated that result in media being looped back to the originator. This document describes a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism to test the media path when SIP sessions go through media-relaying back- to-back user agents (B2BUAs).

RFC 7404 Using Only Link-Local Addressing inside an IPv6 Network

Authors: M. Behringer, E. Vyncke.

Date: November 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7404

In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.

RFC 7405 Case-Sensitive String Support in ABNF

Authors: P. Kyzivat.

Date: December 2014

Formats: txt json html

Updates: RFC 5234

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7405

This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.

RFC 7406 Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices

Authors: H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig, D. Kroeselberg.

Date: December 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7406

This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network.

RFC 7407 A YANG Data Model for SNMP Configuration

Authors: M. Bjorklund, J. Schoenwaelder.

Date: December 2014

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7407

This document defines a collection of YANG definitions for configuring SNMP engines.

RFC 7408 Forwarding and Control Element Separation (ForCES) Model Extension

Authors: E. Haleplidis.

Date: November 2014

Formats: txt json html

Updates: RFC 5812

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7408

This memo extends the Forwarding and Control Element Separation(ForCES) model defined in RFC 5812 and updates that RFC to allow complex data types for metadata, optional default values for data types, and optional access types for structures. It also fixes an issue with Logical Functional Block (LFB) inheritance and introduces two new features: a new event condition called eventBecomesEqualTo and LFB properties. The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models.

RFC 7409 Forwarding and Control Element Separation (ForCES) Packet Parallelization

Authors: E. Haleplidis, J. Halpern.

Date: November 2014

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7409

Many network devices support parallel packet processing. This document describes how Forwarding and Control Element Separation(ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810).

RFC 7410 A Property Types Registry for the Authentication-Results Header Field

Authors: M. Kucherawy.

Date: December 2014

Formats: txt json html

Obsoleted by: RFC 7601

Updates: RFC 7001

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7410

This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values.

RFC 7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers

Authors: T. Schmidt, Ed., M. Waehlisch, R. Koodli, G. Fairhurst, D. Liu.

Date: November 2014

Formats: txt json html

Updates: RFC 5568

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7411

Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6(PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the MobileIPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy MobileIPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy RouterAdvertisements message format.
This document updates RFC 5568, "Mobile IPv6 Fast Handovers".

RFC 7412 Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection

Authors: Y. Weingarten, S. Aldrin, P. Pan, J. Ryoo, G. Mirsky.

Date: December 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7412

This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support. This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLSTransport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP)Survivability Framework"). This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.

RFC 7413 TCP Fast Open

Authors: Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain.

Date: December 2014

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7413

This document describes an experimental TCP mechanism called TCP FastOpen (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake(3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances.Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.

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 7415 Session Initiation Protocol (SIP) Rate Control

Authors: E. Noel, P. Williams.

Date: February 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7415

The prevalent use of the Session Initiation Protocol (SIP) in NextGeneration Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. A loss-based solution to remedy known vulnerabilities of the SIP 503 (Service Unavailable) overload control mechanism has already been proposed. Using the same signaling, this document proposes a rate-based control scheme to complement the loss-based control scheme.

RFC 7416 A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)

Authors: T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, M. Richardson, Ed..

Date: January 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7416

This document presents a security threat analysis for the RoutingProtocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements.

RFC 7417 Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains

Authors: G. Karagiannis, A. Bhargava.

Date: December 2014

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7417

This document specifies extensions to Generic Aggregate RSVP (RFC4860) for support of the Pre-Congestion Notification (PCN) ControlledLoad (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN.

RFC 7418 An IRTF Primer for IETF Participants

Authors: S. Dawkins, Ed..

Date: December 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7418

This document provides a high-level description of things forInternet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the InternetResearch Task Force (IRTF). This document emphasizes differences in expectations between the two organizations.

RFC 7419 Common Interval Support in Bidirectional Forwarding Detection

Authors: N. Akiya, M. Binderberger, G. Mirsky.

Date: December 2014

Formats: txt json html

Updates: RFC 5880

Status: INFORMATIONAL

DOI: 10.17487/RFC 7419

Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to runBFD sessions.
This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals.

RFC 7420 Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module

Authors: A. Koushik, E. Stephan, Q. Zhao, D. King, J. Hardwick.

Date: December 2014

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7420

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling of the PathComputation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path ComputationElement (PCE), or between two PCEs.

RFC 7421 Analysis of the 64-bit Boundary in IPv6 Addressing

Authors: B. Carpenter, Ed., T. Chown, F. Gont, S. Jiang, A. Petrescu, A. Yourtchenko.

Date: January 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7421

The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet.Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary.

RFC 7422 Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments

Authors: C. Donley, C. Grundemann, V. Sarawat, K. Sundaresan, O. Vautrin.

Date: December 2014

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7422

In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response).Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges.Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use.

RFC 7423 Diameter Applications Design Guidelines

Authors: L. Morand, Ed., V. Fajardo, H. Tschofenig.

Date: November 2014

Formats: txt html json

Also: BCP 0193

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7423

The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions.

RFC 7424 Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks

Authors: R. Krishnan, L. Yong, A. Ghanwani, N. So, B. Khasnabish.

Date: January 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7424

Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling. This document explores some of the mechanisms useful for achieving this.

RFC 7425 Adobe's RTMFP Profile for Flash Communication

Authors: M. Thornburgh.

Date: December 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7425

This memo describes how to use Adobe's Secure Real-Time Media FlowProtocol (RTMFP) to transport the video, audio, and data messages ofAdobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication.

RFC 7426 Software-Defined Networking (SDN): Layers and Architecture Terminology

Authors: E. Haleplidis, Ed., K. Pentikousis, Ed., S. Denazis, J. Hadi Salim, D. Meyer, O. Koufopavlou.

Date: January 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7426

Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking ResearchGroup (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer- reviewed literature, the RFC series, and relevant documents by other standards organizations.

RFC 7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)

Authors: T. Kivinen, J. Snyder.

Date: January 2015

Formats: txt html json

Updates: RFC 7296

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7427

The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA).The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited toECDSA; it can also be used with other signature algorithms.

RFC 7428 Transmission of IPv6 Packets over ITU-T G.9959 Networks

Authors: A. Brandt, J. Buron.

Date: February 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7428

This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.

RFC 7429 Distributed Mobility Management: Current Practices and Gap Analysis

Authors: D. Liu, Ed., JC. Zuniga, Ed., P. Seite, H. Chan, CJ. Bernardos.

Date: January 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7429

This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution.

RFC 7430 Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)

Authors: M. Bagnulo, C. Paasch, F. Gont, O. Bonaventure, C. Raiciu.

Date: July 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7430

This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them.

RFC 7431 Multicast-Only Fast Reroute

Authors: A. Karan, C. Filsfils, IJ. Wijnands, Ed., B. Decraene.

Date: August 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7431

As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services.This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only FastReroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) andMultipoint LDP (mLDP).

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 7433 A Mechanism for Transporting User-to-User Call Control Information in SIP

Authors: A. Johnston, J. Rafferty.

Date: January 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7433

There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism.

RFC 7434 Interworking ISDN Call Control User Information with SIP

Authors: K. Drage, Ed., A. Johnston.

Date: January 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7434

The motivation and use cases for interworking and transporting User- to-User Information (UUI) from the ITU-T Digital SubscriberSignalling System No. 1 (DSS1) User-user information element withinSIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of theUser-to-User header field to enable interworking with this ISDN service.
This document covers interworking with both public ISDN and privateISDN capabilities, so the potential interworking with QSIG will also be addressed.
The package is identified by the new value "isdn-uui" of the"purpose" header field parameter.

RFC 7435 Opportunistic Security: Some Protection Most of the Time

Authors: V. Dukhovni.

Date: December 2014

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7435

This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based onOpportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.

RFC 7436 IP-Only LAN Service (IPLS)

Authors: H. Shah, E. Rosen, F. Le Faucheur, G. Heron.

Date: January 2015

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 7436

A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LANService" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destinationMedia Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via theMAC address learning procedures specified in the IEEE's "Media AccessControl (MAC) Bridges". This document specifies the protocol extensions and procedures for support of the IPLS service.
The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learningMAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as EthernetVPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas.

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 7438 Multipoint LDP (mLDP) In-Band Signaling with Wildcards

Authors: IJ. Wijnands, Ed., E. Rosen, A. Gulko, U. Joorde, J. Tantsura.

Date: January 2015

Formats: txt json html

Updates: RFC 6826, RFC 7246

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7438

There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" into an MPLS Multipoint Label SwitchedPath (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or BidirectionalMulticast trees) to be attached to an MPLS Multipoint Label SwitchedPath (MP-LSP). However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP-LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IPAny-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246.

RFC 7439 Gap Analysis for Operating IPv6-Only MPLS Networks

Authors: W. George, Ed., C. Pignataro, Ed..

Date: January 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7439

This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations(or lack thereof) in the context of IPv6-only MPLS functionality.
In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations.However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols.

RFC 7440 TFTP Windowsize Option

Authors: P. Masotta.

Date: January 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7440

The "Trivial File Transfer Protocol" (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN.
This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in "TFTP Option Extension"(RFC 2347).

RFC 7441 Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes

Authors: IJ. Wijnands, E. Rosen, U. Joorde.

Date: January 2015

Formats: txt html json

Updates: RFC 6514

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7441

Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in theirVPNs. It is also desirable to be able to support customers who haveMPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. This document updates RFC 6514.

RFC 7442 Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP)

Authors: Y. Rekhter, R. Aggarwal, N. Leymann, W. Henderickx, Q. Zhao, R. Li.

Date: February 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7442

When IP multicast trees created by Protocol Independent Multicast -Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees toPoint-to-Multipoint Label Switched Paths (P2MP LSPs). This document describes how to accomplish this in the case where such P2MP LSPs are established using Label Distribution Protocol (LDP) Extensions forP2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).

RFC 7443 Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages

Authors: P. Patil, T. Reddy, G. Salgueiro, M. Petit-Huguenin.

Date: January 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7443

Application-Layer Protocol Negotiation (ALPN) labels for SessionTraversal Utilities for NAT (STUN) usages, such as Traversal UsingRelays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer to negotiate STUN usages within the Transport Layer Security (TLS) connection. ALPN protocol identifiers defined in this document apply to both TLS and DatagramTransport Layer Security (DTLS).

RFC 7444 Security Labels in Internet Email

Authors: K. Zeilenga, A. Melnikov.

Date: February 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7444

This document describes a header field, SIO-Label, for use inInternet email to convey the sensitivity of the message. This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. This document also describes a header field, SIO-Label-History, for recording changes in the message's label.

RFC 7445 Analysis of Failure Cases in IPv6 Roaming Scenarios

Authors: G. Chen, H. Deng, D. Michaud, J. Korhonen, M. Boucadair.

Date: March 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7445

This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios.The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks.

RFC 7446 Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks

Authors: Y. Lee, Ed., G. Bernstein, Ed., D. Li, W. Imajuku.

Date: February 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7446

This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength SwitchedOptical Networks (WSONs). The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing aGMPLS control plane are discussed.

RFC 7447 Deprecation of BGP Entropy Label Capability Attribute

Authors: J. Scudder, K. Kompella.

Date: February 2015

Formats: txt json html

Updates: RFC 6790

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7447

The BGP Entropy Label Capability attribute is defined in RFC 6790.Regrettably, it has a bug: although RFC 6790 mandates that routers incapable of processing Entropy Labels must remove the attribute, fulfillment of this requirement cannot be guaranteed in practice.This specification deprecates the attribute. A forthcoming document will propose a replacement.

RFC 7448 MIB Transfer from the IETF to the IEEE 802.3 WG

Authors: T. Taylor, Ed., D. Romascanu.

Date: February 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7448

This document records the transfer of responsibility for theEthernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB,POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB,ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group(WG). This document also describes the procedures associated with the transfer in a similar way to how RFC 4663 records the transfer of the IETF Bridge MIB work to the IEEE 802.1 WG.

RFC 7449 Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment

Authors: Y. Lee, Ed., G. Bernstein, Ed., J. Martensson, T. Takeda, T. Tsuritani, O. Gonzalez de Dios.

Date: February 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7449

This memo provides application-specific requirements for the PathComputation Element Communication Protocol (PCEP) for the support ofWavelength Switched Optical Networks (WSONs). Lightpath provisioning in WSONs requires a Routing and Wavelength Assignment (RWA) process.From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document.

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 7451 Extension Registry for the Extensible Provisioning Protocol

Authors: S. Hollenbeck.

Date: February 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7451

The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.

RFC 7452 Architectural Considerations in Smart Object Networking

Authors: H. Tschofenig, J. Arkko, D. Thaler, D. McPherson.

Date: March 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7452

The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered byInternet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment.Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.
This document offers guidance to engineers designing Internet- connected smart objects.

RFC 7453 MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB)

Authors: V. Mahalingam, K. Sampath, S. Aldrin, T. Nadeau.

Date: February 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7453

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 additional managed objects and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks.

RFC 7454 BGP Operations and Security

Authors: J. Durand, I. Pepelnjak, G. Doering.

Date: February 2015

Formats: txt html json

Also: BCP 0194

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7454

The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.
This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System(AS) path filtering, route flap dampening, and BGP community scrubbing.

RFC 7455 Transparent Interconnection of Lots of Links (TRILL): Fault Management

Authors: T. Senevirathne, N. Finn, S. Salam, D. Kumar, D. Eastlake 3rd, S. Aldrin, Y. Li.

Date: March 2015

Formats: txt html json

Updates: RFC 6325

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7455

This document specifies Transparent Interconnection of Lots of Links(TRILL) Operations, Administration, and Maintenance (OAM) fault management. Methods in this document follow the CFM (ConnectivityFault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL- specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1.This document updates RFC 6325.

RFC 7456 Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)

Authors: T. Mizrahi, T. Senevirathne, S. Salam, D. Kumar, D. Eastlake 3rd.

Date: March 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7456

Performance Monitoring (PM) is a key aspect of Operations,Administration, and Maintenance (OAM). It allows network operators to verify the Service Level Agreement (SLA) provided to customers and to detect network anomalies. This document specifies mechanisms forLoss Measurement and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) networks.

RFC 7457 Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)

Authors: Y. Sheffer, R. Holz, P. Saint-Andre.

Date: February 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7457

Over the last few years, there have been several serious attacks onTransport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and DatagramTLS (DTLS).

RFC 7458 Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core

Authors: R. Valmikam, R. Koodli.

Date: February 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7458

With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well.Such functions include Access Point Name (APN) Selection, multiplePacket Data Network (PDN) connections, and seamless mobility betweenWi-Fi and 3G/4G networks.
The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile EvolvedPacket Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as aMobile Node (MN)) and its network counterpart (such as anAuthentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure.

RFC 7459 Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO)

Authors: M. Thomson, J. Winterbottom.

Date: February 2015

Formats: txt html json

Updates: RFC 3693, RFC 4119, RFC 5491

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7459

This document defines key concepts of uncertainty and confidence as they pertain to location information. Methods for the manipulation of location estimates that include uncertainty information are outlined.
This document normatively updates the definition of location information representations defined in RFCs 4119 and 5491. It also deprecates related terminology defined in RFC 3693.

RFC 7460 Monitoring and Control MIB for Power and Energy

Authors: M. Chandramouli, B. Claise, B. Schoening, J. Quittek, T. Dietz.

Date: March 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7460

This document defines a subset of the Management Information Base(MIB) for power and energy monitoring of devices.

RFC 7461 Energy Object Context MIB

Authors: J. Parello, B. Claise, M. Chandramouli.

Date: March 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7461

This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the energy relationships between devices.

RFC 7462 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)

Authors: L. Liess, Ed., R. Jesske, A. Johnston, D. Worley, P. Kyzivat.

Date: March 2015

Formats: txt json html

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7462

The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UserAgent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.
This document normatively updates RFC 3261, which defines the SessionInitiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values.

RFC 7463 Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)

Authors: A. Johnston, Ed., M. Soroushnejad, Ed., V. Venkataramanan.

Date: March 2015

Formats: txt json html

Updates: RFC 3261, RFC 4235

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7463

This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance(BLA) or Multiple Line Appearance (MLA), or Shared Call/LineAppearance (SCA). When implemented using the Session InitiationProtocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP PrivateBranch Exchange (IPBX) offerings and is likely to be implemented onSIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements, and defines extensions to implement this feature. This specification updates RFCs 3261 and4235.

RFC 7464 JavaScript Object Notation (JSON) Text Sequences

Authors: N. Williams.

Date: February 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7464

This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". AJSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).

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 7466 An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)

Authors: C. Dearlove, T. Clausen.

Date: March 2015

Formats: txt json html

Updates: RFC 6130, RFC 7181

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7466

The link quality mechanism of the Mobile Ad Hoc Network (MANET)Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.
NHDP also collects information about symmetric 2-hop neighbors.However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed.This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment.
This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET)Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The OptimizedLink State Routing Protocol Version 2 (OLSRv2)" to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more"robust".

RFC 7467 URN Namespace for the North Atlantic Treaty Organization (NATO)

Authors: A. Murdock.

Date: April 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7467

This document allocates a formal Uniform Resource Name (URN) namespace for assignment by the North Atlantic Treaty Organization(NATO), as specified in RFC 3406. At this time, the URN will be used primarily to uniquely identify Extensible Markup Language (XML) artefacts that provide information about NATO message text formats and service specifications as described in various NATO standards, instructions, and publications.

RFC 7468 Textual Encodings of PKIX, PKCS, and CMS Structures

Authors: S. Josefsson, S. Leonard.

Date: April 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7468

This document describes and discusses the textual encodings of thePublic-Key Infrastructure X.509 (PKIX), Public-Key CryptographyStandards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.

RFC 7469 Public Key Pinning Extension for HTTP

Authors: C. Evans, C. Palmer, R. Sleevi.

Date: April 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7469

This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromisedCertification Authorities.

RFC 7470 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol

Authors: F. Zhang, A. Farrel.

Date: March 2015

Formats: txt html json

Obsoletes: RFC 7150

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7470

The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between PathComputation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.
This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs.
This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object.

RFC 7471 OSPF Traffic Engineering (TE) Metric Extensions

Authors: S. Giacalone, D. Ward, J. Drake, A. Atlas, S. Previdi.

Date: March 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7471

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.
This document describes common extensions to RFC 3630 "TrafficEngineering (TE) Extensions to OSPF Version 2" and RFC 5329 "TrafficEngineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.
Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.

RFC 7472 Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme

Authors: I. McDonald, M. Sweet.

Date: March 2015

Formats: txt json html

Updates: RFC 2910, RFC 2911

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7472

This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.
This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.
This document updates RFCs 2910 and 2911.

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 7474 Security Extension for OSPFv2 When Using Manual Key Management

Authors: M. Bhatia, S. Hartman, D. Zhang, A. Lindem, Ed..

Date: April 2015

Formats: txt html json

Updates: RFC 2328, RFC 5709

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7474

The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.
This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.

RFC 7475 Increasing the Number of Area Directors in an IETF Area

Authors: S. Dawkins.

Date: March 2015

Formats: txt html json

Updates: RFC 2026, RFC 2418

Also: BCP 0009

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7475

This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).

RFC 7476 Information-Centric Networking: Baseline Scenarios

Authors: K. Pentikousis, Ed., B. Ohlman, D. Corujo, G. Boggia, G. Tyson, E. Davies, A. Molinaro, S. Eum.

Date: March 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7476

This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG).

RFC 7477 Child-to-Parent Synchronization in DNS

Authors: W. Hardaker.

Date: March 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7477

This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy.

RFC 7478 Web Real-Time Communication Use Cases and Requirements

Authors: C. Holmberg, S. Hakansson, G. Eriksson.

Date: March 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7478

This document describes web-based real-time communication use cases.Requirements on the browser functionality are derived from the use cases.
This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future.

RFC 7479 Using Ed25519 in SSHFP Resource Records

Authors: S. Moonesamy.

Date: March 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7479

The Ed25519 signature algorithm has been implemented in OpenSSH.This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519.

RFC 7480 HTTP Usage in the Registration Data Access Protocol (RDAP)

Authors: A. Newton, B. Ellacott, N. Kong.

Date: March 2015

Formats: txt html json

Also: STD 0095

Status: INTERNET STANDARD

DOI: 10.17487/RFC 7480

This document is one of a collection that together describes theRegistration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.

RFC 7481 Security Services for the Registration Data Access Protocol (RDAP)

Authors: S. Hollenbeck, N. Kong.

Date: March 2015

Formats: txt html json

Also: STD 0095

Status: INTERNET STANDARD

DOI: 10.17487/RFC 7481

The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name andRegional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP.

RFC 7482 Registration Data Access Protocol (RDAP) Query Format

Authors: A. Newton, S. Hollenbeck.

Date: March 2015

Formats: txt json html

Obsoleted by: RFC 9082

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7482

This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries(including both Regional Internet Registries (RIRs) and Domain NameRegistries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration DataAccess Protocol (RDAP).

RFC 7483 JSON Responses for the Registration Data Access Protocol (RDAP)

Authors: A. Newton, S. Hollenbeck.

Date: March 2015

Formats: txt json html

Obsoleted by: RFC 9083

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7483

This document describes JSON data structures representing registration information maintained by Regional Internet Registries(RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses.

RFC 7484 Finding the Authoritative Registration Data (RDAP) Service

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 7485 Inventory and Analysis of WHOIS Registration Objects

Authors: L. Zhou, N. Kong, S. Shen, S. Sheng, A. Servin.

Date: March 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7485

WHOIS output objects from registries, including both RegionalInternet Registries (RIRs) and Domain Name Registries (DNRs), were collected and analyzed. This document describes the process and results of the statistical analysis of existing WHOIS information.The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration DataAccess Protocol (RDAP) responses.

RFC 7486 HTTP Origin-Bound Authentication (HOBA)

Authors: S. Farrell, P. Hoffman, M. Thomas.

Date: March 2015

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7486

HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.

RFC 7487 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE

Authors: E. Bellagamba, A. Takacs, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward.

Date: March 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7487

This specification describes the configuration of proactive MPLSTransport Profile (MPLS-TP) Operations, Administration, andMaintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE.

RFC 7488 Port Control Protocol (PCP) Server Selection

Authors: M. Boucadair, R. Penno, D. Wing, P. Patil, T. Reddy.

Date: March 2015

Formats: txt html json

Updates: RFC 6887

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7488

This document specifies the behavior to be followed by a Port ControlProtocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured.
This document updates RFC 6887.

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 7490 Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)

Authors: S. Bryant, C. Filsfils, S. Previdi, M. Shand, N. So.

Date: April 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7490

This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.

RFC 7491 A PCE-Based Architecture for Application-Based Network Operations

Authors: D. King, A. Farrel.

Date: March 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7491

Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to- point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations(ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.
This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications.

RFC 7492 Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines

Authors: M. Bhatia, D. Zhang, M. Jethanandani.

Date: March 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7492

This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC6518, "Keying and Authentication for Routing Protocols (KARP) DesignGuidelines".

RFC 7493 The I-JSON Message Format

Authors: T. Bray, Ed..

Date: March 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7493

I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.

RFC 7494 IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP)

Authors: C. Shao, H. Deng, R. Pazhyannur, F. Bari, R. Zhang, S. Matsushima.

Date: April 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7494

The Control and Provisioning of Wireless Access Points (CAPWAP) protocol binding for IEEE 802.11 defines two Medium Access Control(MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs):Split and Local MAC. In the Split MAC mode, the partitioning of encryption/decryption functions is not clearly defined. In the SplitMAC mode description, IEEE 802.11 encryption is specified as located in either the Access Controller (AC) or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11MAC Profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP andAC.

RFC 7495 Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF)

Authors: A. Montville, D. Black.

Date: March 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7495

The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEFReference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information.
This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not updateIODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references.

RFC 7496 Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension

Authors: M. Tuexen, R. Seggelmann, R. Stewart, S. Loreto.

Date: April 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7496

This document defines two additional policies for the PartiallyReliable Stream Control Transmission Protocol (PR-SCTP) extension.These policies allow limitation of the number of retransmissions and prioritization of user messages for more efficient usage of the send buffer.

RFC 7497 Rate Measurement Test Protocol Problem Statement and Requirements

Authors: A. Morton.

Date: April 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7497

This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size.

RFC 7498 Problem Statement for Service Function Chaining

Authors: P. Quinn, Ed., T. Nadeau, Ed..

Date: April 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7498

This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.
The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy.
This document also identifies several key areas that the ServiceFunction Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents.

RFC 7499 Support of Fragmentation of RADIUS Packets

Authors: A. Perez-Mendez, Ed., R. Marin-Lopez, F. Pereniguez-Garcia, G. Lopez-Millan, D. Lopez, A. DeKok.

Date: April 2015

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7499

The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers.

RFC 7500 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries

Authors: R. Housley, Ed., O. Kolkman, Ed..

Date: April 2015

Formats: txt html json

Obsoleted by: RFC 8720

Status: INFORMATIONAL

DOI: 10.17487/RFC 7500

This document provides principles for the operation of InternetAssigned Numbers Authority (IANA) registries.

RFC 7501 Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration

Authors: C. Davids, V. Gurbani, S. Poretsky.

Date: April 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7501

This document provides a terminology for benchmarking the SessionInitiation Protocol (SIP) performance of devices. Methodology related to benchmarking SIP devices is described in the companion methodology document (RFC 7502). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session BorderControllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages.Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements. A standard terminology and methodology will ensure that benchmarks have consistent definitions and were obtained following the same procedures.

RFC 7502 Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration

Authors: C. Davids, V. Gurbani, S. Poretsky.

Date: April 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7502

This document provides a methodology for benchmarking the SessionInitiation Protocol (SIP) performance of devices. Terminology related to benchmarking SIP devices is described in the companion terminology document (RFC 7501). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session BorderControllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages.Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements.

RFC 7503 OSPFv3 Autoconfiguration

Authors: A. Lindem, J. Arkko.

Date: April 2015

Formats: txt json html

Updates: RFC 5340

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7503

OSPFv3 is a candidate for deployments in environments where autoconfiguration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring.This document updates RFC 5340 by relaxing the HelloInterval/RouterDeadInterval checking during OSPFv3 adjacency formation and adding hysteresis to the update of self-originated Link StateAdvertisements (LSAs).

RFC 7504 SMTP 521 and 556 Reply Codes

Authors: J. Klensin.

Date: June 2015

Formats: txt html json

Updates: RFC 1846, RFC 5321

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7504

This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in anExperimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created to support the new tests and actions specified in RFC 7505. These codes are used to indicate that an Internet host does not accept incoming mail at all. This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances.

RFC 7505 A "Null MX" No Service Resource Record for Domains That Accept No Mail

Authors: J. Levine, M. Delany.

Date: June 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7505

Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for anA/AAAA record as a fallback. Unfortunately, this means that theA/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.

RFC 7506 IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)

Authors: K. Raza, N. Akiya, C. Pignataro.

Date: April 2015

Formats: txt json html

Updates: RFC 4379

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7506

RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute mechanism in which the Router Alert Option (RAO) MUST be set in theIP header of the MPLS Echo Request messages and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on theReply Mode used. While a generic "Router shall examine packet"Option Value is used for the IPv4 RAO, there is no generic RAO value defined for IPv6 that can be used. This document allocates a new, generic IPv6 RAO value that can be used by MPLS Operations,Administration, and Maintenance (OAM) tools, including the MPLS EchoRequest and MPLS Echo Reply messages for MPLS in IPv6 environments.Consequently, it updates RFC 4379.
The initial motivation to request an IPv6 RAO value for MPLS OAM comes from the MPLS LSP Ping/Traceroute. However, this value is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute.

RFC 7507 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks

Authors: B. Moeller, A. Langley.

Date: April 2015

Formats: txt json html

Obsoleted by: RFC 8996

Updates: RFC 2246, RFC 4346, RFC 4347, RFC 5246, RFC 6347

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7507

This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security(TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included.

RFC 7508 Securing Header Fields with S/MIME

Authors: L. Cailleux, C. Bonatti.

Date: April 2015

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7508

This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322. This technology provides security services such as data integrity, non- repudiation, and confidentiality. This extension is referred to as'Secure Headers'.

RFC 7509 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics

Authors: R. Huang, V. Singh.

Date: May 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7509

This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system.

RFC 7510 Encapsulating MPLS in UDP

Authors: X. Xu, N. Sheth, L. Yong, R. Callon, D. Black.

Date: April 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7510

This document specifies an IP-based encapsulation for MPLS, calledMPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enableUDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6.

RFC 7511 Scenic Routing for IPv6

Authors: M. Wilhelm.

Date: 1 April 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7511

This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "GreenIT", whereby packets will be routed to get as much fresh-air time as possible.

RFC 7512 The PKCS #11 URI Scheme

Authors: J. Pechanec, D. Moffat.

Date: April 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7512

This memo specifies a PKCS #11 Uniform Resource Identifier (URI)Scheme for identifying PKCS #11 objects stored in PKCS #11 tokens and also for identifying PKCS #11 tokens, slots, or libraries. The URI scheme is based on how PKCS #11 objects, tokens, slots, and libraries are identified in "PKCS #11 v2.20: Cryptographic Token InterfaceStandard".

RFC 7513 Source Address Validation Improvement (SAVI) Solution for DHCP

Authors: J. Bi, J. Wu, G. Yao, F. Baker.

Date: May 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7513

This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a SourceAddress Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.

RFC 7514 Really Explicit Congestion Notification (RECN)

Authors: M. Luckie.

Date: 1 April 2015

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7514

This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss andExplicit Congestion Notification (ECN).

RFC 7515 JSON Web Signature (JWS)

Authors: M. Jones, J. Bradley, N. Sakimura.

Date: May 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7515

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON WebAlgorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.

RFC 7516 JSON Web Encryption (JWE)

Authors: M. Jones, J. Hildebrand.

Date: May 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7516

JSON Web Encryption (JWE) represents encrypted content usingJSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSONWeb Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and MessageAuthentication Code (MAC) capabilities are described in the separateJSON Web Signature (JWS) specification.

RFC 7517 JSON Web Key (JWK)

Authors: M. Jones.

Date: May 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7517

A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set ofJWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.

RFC 7518 JSON Web Algorithms (JWA)

Authors: M. Jones.

Date: May 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7518

This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption(JWE), and JSON Web Key (JWK) specifications. It defines severalIANA registries for these identifiers.

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 7520 Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)

Authors: M. Miller.

Date: May 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7520

This document contains a set of examples using JSON Object Signing and Encryption (JOSE) technology to protect data. These examples present a representative sampling of JSON Web Key (JWK) objects as well as various JSON Web Signature (JWS) and JSON Web Encryption(JWE) results given similar inputs.

RFC 7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants

Authors: B. Campbell, C. Mortimore, M. Jones, Y. Goland.

Date: May 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7521

This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified.
The intent of this specification is to provide a common framework forOAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.
Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.

RFC 7522 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants

Authors: B. Campbell, C. Mortimore, M. Jones.

Date: May 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7522

This specification defines the use of a Security Assertion MarkupLanguage (SAML) 2.0 Bearer Assertion as a means for requesting anOAuth 2.0 access token as well as for client authentication.

RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

Authors: M. Jones, B. Campbell, C. Mortimore.

Date: May 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7523

This specification defines the use of a JSON Web Token (JWT) BearerToken as a means for requesting an OAuth 2.0 access token as well as for client authentication.

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 7526 Deprecating the Anycast Prefix for 6to4 Relay Routers

Authors: O. Troan, B. Carpenter, Ed..

Date: May 2015

Formats: txt json html

Obsoletes: RFC 3068, RFC 6732

Also: BCP 0196

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7526

Experience with the 6to4 transition mechanism defined in RFC 3056("Connection of IPv6 Domains via IPv4 Clouds") has shown that the mechanism is unsuitable for widespread deployment and use in theInternet when used in its anycast mode. Therefore, this document requests that RFC 3068 ("An Anycast Prefix for 6to4 Relay Routers") and RFC 6732 ("6to4 Provider Managed Tunnels") be made obsolete and moved to Historic status. It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343.

RFC 7527 Enhanced Duplicate Address Detection

Authors: R. Asati, H. Singh, W. Beebee, C. Pignataro, E. Dart, W. George.

Date: April 2015

Formats: txt json html

Updates: RFC 4429, RFC 4861, RFC 4862

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7527

IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. Several service provider communities have expressed a need for automated detection of looped back NeighborDiscovery (ND) messages used by DAD. This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the detection of looped back IPv6 ND messages used by DAD.For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks, this document automates resolving a specific duplicate address conflict. This document updates RFCs 4429, 4861, and 4862.

RFC 7528 A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association

Authors: P. Higgs, J. Piesing.

Date: April 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7528

This document describes a Uniform Resource Name (URN) namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association for naming persistent resources defined within HbbTV specifications. Example resources include technical documents and specifications, ExtensibleMarkup Language (XML) Schemas, classification schemes, XML DocumentType Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by HbbTV.

RFC 7529 Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar)

Authors: C. Daboo, G. Yakushev.

Date: May 2015

Formats: txt html json

Updates: RFC 5545, RFC 6321, RFC 7265

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7529

This document defines extensions to the Internet Calendaring andScheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines howCalendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules.

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 7531 Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description

Authors: T. Haynes, Ed., D. Noveck, Ed..

Date: March 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7531

The Network File System (NFS) version 4 protocol is a distributed file system protocol that owes its heritage to NFS protocol version 2(RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, theNFS 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.
RFC 7530 formally obsoletes RFC 3530. This document, together withRFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol.

RFC 7532 Namespace Database (NSDB) Protocol for Federated File Systems

Authors: J. Lentini, R. Tewari, C. Lever, Ed..

Date: March 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7532

This document describes a file system federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.

RFC 7533 Administration Protocol for Federated File Systems

Authors: J. Lentini, R. Tewari, C. Lever, Ed..

Date: March 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7533

This document describes the administration protocol for a federated file system (FedFS) that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.

RFC 7534 AS112 Nameserver Operations

Authors: J. Abley, W. Sotomayor.

Date: May 2015

Formats: txt html json

Obsoletes: RFC 6304

Status: INFORMATIONAL

DOI: 10.17487/RFC 7534

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated inRFC 1918 for private use within individual sites.
Devices in such environments may occasionally originate Domain NameSystem (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.
It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.
This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation.
This document obsoletes RFC 6304.

RFC 7535 AS112 Redirection Using DNAME

Authors: J. Abley, B. Dickson, W. Kumari, G. Michaelson.

Date: May 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7535

AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records.
This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.

RFC 7536 Large-Scale Broadband Measurement Use Cases

Authors: M. Linsner, P. Eardley, T. Burbridge, F. Sorensen.

Date: May 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7536

Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the Large-scaleMeasurement of Broadband Performance (LMAP) framework, information model, and protocol. This document details two use cases that can assist in developing that framework. The details of the measurement metrics themselves are beyond the scope of this document.

RFC 7537 IANA Registries for LSP Ping Code Points

Authors: B. Decraene, N. Akiya, C. Pignataro, L. Andersson, S. Aldrin.

Date: May 2015

Formats: txt json html

Obsoleted by: RFC 8029

Updates: RFC 4379, RFC 6424

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7537

RFCs 4379 and 6424 created name spaces for Multi-Protocol LabelSwitching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for DownstreamMapping object Flags (DS Flags), Multipath Types, Pad TLVs, andInterface and Label Stack Address Types.
There is now a need to make further code point allocations from these name spaces. This document updates RFCs 4379 and 6424 in that it creates IANA registries for that purpose.

RFC 7538 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)

Authors: J. Reschke.

Date: April 2015

Formats: txt html json

Obsoletes: RFC 7238

Obsoleted by: RFC 9110

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7538

This document specifies the additional Hypertext Transfer Protocol(HTTP) status code 308 (Permanent Redirect).

RFC 7539 ChaCha20 and Poly1305 for IETF Protocols

Authors: Y. Nir, A. Langley.

Date: May 2015

Formats: txt html json

Obsoleted by: RFC 8439

Status: INFORMATIONAL

DOI: 10.17487/RFC 7539

This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data(AEAD) algorithm.
This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG).

RFC 7540 Hypertext Transfer Protocol Version 2 (HTTP/2)

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 7541 HPACK: Header Compression for HTTP/2

Authors: R. Peon, H. Ruellan.

Date: May 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7541

This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.

RFC 7542 The Network Access Identifier

Authors: A. DeKok.

Date: May 2015

Formats: txt html json

Obsoletes: RFC 4282

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7542

In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282.

RFC 7543 Covering Prefixes Outbound Route Filter for BGP-4

Authors: H. Jeng, L. Jalil, R. Bonica, K. Patel, L. Yong.

Date: May 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7543

This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in VirtualHub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN(EVPN) networks.

RFC 7544 Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP)

Authors: M. Mohali.

Date: August 2015

Formats: txt json html

Obsoletes: RFC 6044

Status: INFORMATIONAL

DOI: 10.17487/RFC 7544

Although the SIP History-Info header field described in RFC 7044 is the solution adopted in IETF, the non-standard Diversion header field described, as Historic, in RFC 5806 is nevertheless already implemented and used for conveying call-diversion-related information in Session Initiation Protocol (SIP) signaling.
RFC 7044 obsoletes the original RFC 4244 and redefines the History-Info header field for capturing the history information in requests.
Since the Diversion header field is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This document describes a recommended interworking guideline between the Diversion header field and the History-Info header field to handle call diversion information. This work is intended to enable the migration from non-standard implementations toward IETF specification-based implementations.
This document obsoletes RFC 6044, which describes the interworking between the Diversion header field defined in RFC 5806 and the obsoleted History-Info header field defined on RFC 4244.

RFC 7545 Protocol to Access White-Space (PAWS) Databases

Authors: V. Chen, Ed., S. Das, L. Zhu, J. Malyar, P. McCann.

Date: May 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7545

Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called"white space". Allowing secondary users access to available spectrum"unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization.
One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the"Protocol to Access White-Space (PAWS) Databases".

RFC 7546 Structure of the Generic Security Service (GSS) Negotiation Loop

Authors: B. Kaduk.

Date: May 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7546

This document specifies the generic structure of the negotiation loop to establish a Generic Security Service (GSS) security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application-specific behavior must be specified.

RFC 7547 Management of Networks with Constrained Devices: Problem Statement and Requirements

Authors: M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, U. Herberg.

Date: May 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7547

This document provides a problem statement, deployment and management topology options, as well as requirements addressing the different use cases of the management of networks where constrained devices are involved.

RFC 7548 Management of Networks with Constrained Devices: Use Cases

Authors: M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, A. Sehgal.

Date: May 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7548

This document discusses use cases concerning the management of networks in which constrained devices are involved. A problem statement, deployment options, and the requirements on the networks with constrained devices can be found in the companion document on"Management of Networks with Constrained Devices: Problem Statement and Requirements" (RFC 7547).

RFC 7549 3GPP SIP URI Inter-Operator Traffic Leg Parameter

Authors: C. Holmberg, J. Holm, R. Jesske, M. Dolly.

Date: May 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7549

In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-BackUser Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg.
This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).
The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible.

RFC 7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options

Authors: O. Troan, B. Volz, M. Siodelski.

Date: May 2015

Formats: txt json html

Obsoleted by: RFC 8415

Updates: RFC 3315, RFC 3633

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7550

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA_NA and IA_TA, but did not anticipate the development of additional stateful options.DHCPv6 Prefix Delegation added the IA_PD option, which is stateful.Applications that use IA_NA and IA_PD together have revealed issues that need to be addressed. This document updates RFCs 3315 and 3633 to address these issues.

RFC 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 7552 Updates to LDP for IPv6

Authors: R. Asati, C. Pignataro, K. Raza, V. Manral, R. Papneja.

Date: June 2015

Formats: txt html json

Updates: RFC 5036, RFC 6720

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7552

The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 networks, or both. This document corrects and clarifies the LDP behavior when an IPv6 network is used (with or without IPv4). This document updates RFCs 5036 and 6720.

RFC 7553 The Uniform Resource Identifier (URI) DNS Resource Record

Authors: P. Faltstrom, O. Kolkman.

Date: June 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7553

This document describes the already registered DNS resource record(RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs.

RFC 7554 Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement

Authors: T. Watteyne, Ed., M. Palattella, L. Grieco.

Date: May 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7554

This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium AccessControl (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only.

RFC 7555 Proxy MPLS Echo Request

Authors: G. Swallow, V. Lim, S. Aldrin.

Date: June 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7555

This document defines a means of remotely initiating MultiprotocolLabel Switched Protocol (MPLS) Pings on Label Switched Paths. AnMPLS Proxy Ping Request is sent to any Label Switching Router along aLabel Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root).

RFC 7556 Multiple Provisioning Domain Architecture

Authors: D. Anipko, Ed..

Date: June 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7556

This document is a product of the work of the Multiple InterfacesArchitecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of aProvisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.

RFC 7557 Extension Mechanism for the Babel Routing Protocol

Authors: J. Chroboczek.

Date: May 2015

Formats: txt html json

Obsoleted by: RFC 8966

Updates: RFC 6126

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7557

This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.

RFC 7558 Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions

Authors: K. Lynn, S. Cheshire, M. Blanchet, D. Migault.

Date: July 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7558

DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements for scalableDNS-SD.

RFC 7559 Packet-Loss Resiliency for Router Solicitations

Authors: S. Krishnan, D. Anipko, D. Thaler.

Date: May 2015

Formats: txt json html

Updates: RFC 4861

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7559

When an interface on a host is initialized, the host transmits RouterSolicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these Router Solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial RouterSolicitations.

RFC 7560 Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback

Authors: M. Kuehlewind, Ed., R. Scheffenegger, B. Briscoe.

Date: August 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7560

Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets, instead of dropping them, to indicate congestion to the endpoints. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-TripTime (RTT). In contrast, ECN for other transport protocols, such asRTP/UDP and SCTP, is specified with more accurate ECN feedback.Recent new TCP mechanisms (like Congestion Exposure (ConEx) or DataCenter TCP (DCTCP)) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback.

RFC 7561 Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN

Authors: J. Kaippallimalil, R. Pazhyannur, P. Yegani.

Date: June 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7561

This document provides guidelines for achieving end-to-end Quality ofService (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11 andWi-Fi Multimedia - Admission Control (WMM-AC) describe methods forQoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters.This document is intended to be used as a companion document to RFC7222 to enable implementation of end-to-end QoS.

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 7563 Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option

Authors: R. Pazhyannur, S. Speicher, S. Gundavelli, J. Korhonen, J. Kaippallimalil.

Date: June 2015

Formats: txt html json

Updates: RFC 6757

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7563

The Access Network Identifier (ANI) mobility option was introduced inRFC 6757, "Access Network Identifier (ANI) Option for Proxy MobileIPv6". This enables a Mobile Access Gateway (MAG) to convey identifiers like the network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub-options to carry the civic location and theMAG group identifier. This specification also defines an ANI Update-Timer sub-option that determines when and how often the ANI option will be updated.

RFC 7564 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols

Authors: P. Saint-Andre, M. Blanchet.

Date: May 2015

Formats: txt json html

Obsoletes: RFC 3454

Obsoleted by: RFC 8264

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7564

Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known asStringprep (RFC 3454). This document obsoletes RFC 3454.

RFC 7565 The 'acct' URI Scheme

Authors: P. Saint-Andre.

Date: May 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7565

This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.

RFC 7566 Enumservice Registration for 'acct' URI

Authors: L. Goix, K. Li.

Date: June 2015

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7566

This document registers an E.164 Number Mapping (ENUM) service for'acct' URIs (Uniform Resource Identifiers).

RFC 7567 IETF Recommendations Regarding Active Queue Management

Authors: F. Baker, Ed., G. Fairhurst, Ed..

Date: July 2015

Formats: txt html json

Obsoletes: RFC 2309

Also: BCP 0197

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7567

This memo presents 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 (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.
Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.

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 7569 Registry Specification for Mandatory Access Control (MAC) Security Label Formats

Authors: D. Quigley, J. Lu, T. Haynes.

Date: July 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7569

In the past, Mandatory Access Control (MAC) systems have used very rigid policies that were implemented in particular protocols and platforms. As MAC systems become more widely deployed, additional flexibility in mechanism and policy will be required. While traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include such technologies as type enforcement. Due to the wide range of policies and mechanisms that need to be accommodated, it is unlikely that the use of a single security label format and model will be viable.
To allow multiple MAC mechanisms and label formats to co-exist in a network, this document creates a registry of label format specifications. This registry contains label format identifiers and provides for the association of each such identifier with a corresponding extensive document outlining the exact syntax and use of the particular label format.

RFC 7570 Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)

Authors: C. Margaria, Ed., G. Martinelli, S. Balls, B. Wright.

Date: July 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7570

RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop.

RFC 7571 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback

Authors: J. Dong, M. Chen, Z. Li, D. Ceccarelli.

Date: July 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7571

This document specifies extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) andLoopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS(GMPLS) for the control plane.

RFC 7572 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging

Authors: P. Saint-Andre, A. Houri, J. Hildebrand.

Date: June 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7572

This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session InitiationProtocol (SIP) and the Extensible Messaging and Presence Protocol(XMPP).

RFC 7573 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions

Authors: P. Saint-Andre, S. Loreto.

Date: June 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7573

This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP).Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).

RFC 7574 Peer-to-Peer Streaming Peer Protocol (PPSPP)

Authors: A. Bakker, R. Petrocco, V. Grishchenko.

Date: July 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7574

The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both prerecorded (on- demand) and live audio/video content. It is based on the peer-to- peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers.PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes(centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP usingLow Extra Delay Background Transport (LEDBAT) for congestion control.

RFC 7575 Autonomic Networking: Definitions and Design Goals

Authors: M. Behringer, M. Pritikin, S. Bjarnason, A. Clemm, B. Carpenter, S. Jiang, L. Ciavaglia.

Date: June 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7575

Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements.
This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an AutonomicNetwork interact. This document is a product of the IRTF's NetworkManagement Research Group.

RFC 7576 General Gap Analysis for Autonomic Networking

Authors: S. Jiang, B. Carpenter, M. Behringer.

Date: June 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7576

This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept.
This document is a product of the IRTF's Network Management ResearchGroup.

RFC 7577 Definition of Managed Objects for Battery Monitoring

Authors: J. Quittek, R. Winter, T. Dietz.

Date: July 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7577

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 managed objects that provide information on the status of batteries in managed devices.

RFC 7578 Returning Values from Forms: multipart/form-data

Authors: L. Masinter.

Date: July 2015

Formats: txt json html

Obsoletes: RFC 2388

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7578

This specification defines the multipart/form-data media type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. This document obsoletesRFC 2388.

RFC 7579 General Network Element Constraint Encoding for GMPLS-Controlled Networks

Authors: G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han.

Date: June 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7579

Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links.
This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.

RFC 7580 OSPF-TE Extensions for General Network Element Constraints

Authors: F. Zhang, Y. Lee, J. Han, G. Bernstein, Y. Xu.

Date: June 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7580

Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching(e.g., MPLS), time division (e.g., Synchronous Optical Network /Synchronous Digital Hierarchy (SONET/SDH) and Optical TransportNetwork (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links. This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control ofGMPLS.

RFC 7581 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks

Authors: G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han.

Date: June 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7581

A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength AssignmentInformation Model for Wavelength Switched Optical Networks" (RFC7446) shows what information is required at specific points in theWSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs.
This document provides efficient, protocol-agnostic encodings for theWSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE).

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 7583 DNSSEC Key Rollover Timing Considerations

Authors: S. Morris, J. Ihren, J. Dickinson, W. Mekking.

Date: October 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7583

This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.

RFC 7584 Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs)

Authors: R. Ravindranath, T. Reddy, G. Salgueiro.

Date: July 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7584

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing.
This document defines behavior for a B2BUA performing ICE processing.The goal of this document is to ensure that B2BUAs properly handleSIP messages that carry ICE semantics in Session Description Protocol(SDP) and STUN messages received as part of the ICE procedures forNAT and Firewall traversal of multimedia sessions.

RFC 7585 Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)

Authors: S. Winter, M. McCauley.

Date: October 2015

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7585

This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS overTransport Layer Security (RADIUS/TLS) or RADIUS over DatagramTransport Layer Security (RADIUS/DTLS).

RFC 7586 The Scalable Address Resolution Protocol (SARP) for Large Data Centers

Authors: Y. Nachum, L. Dunbar, I. Yerushalmi, T. Mizrahi.

Date: June 2015

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7586

This document introduces the Scalable Address Resolution Protocol(SARP), an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations. SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations.

RFC 7587 RTP Payload Format for the Opus Speech and Audio Codec

Authors: J. Spittka, K. Vos, JM. Valin.

Date: June 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7587

This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP.Further, it describes media type registrations for the RTP payload format.

RFC 7588 A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem

Authors: R. Bonica, C. Pignataro, J. Touch.

Date: July 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7588

This memo describes how many vendors have solved the Generic RoutingEncapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration.

RFC 7589 Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication

Authors: M. Badra, A. Luchuk, J. Schoenwaelder.

Date: June 2015

Formats: txt json html

Obsoletes: RFC 5539

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7589

The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices.This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange ofNETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539.

RFC 7590 Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)

Authors: P. Saint-Andre, T. Alkemade.

Date: June 2015

Formats: txt json html

Updates: RFC 6120

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7590

This document provides recommendations for the use of Transport LayerSecurity (TLS) in the Extensible Messaging and Presence Protocol(XMPP). This document updates RFC 6120.

RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol

Authors: J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt.

Date: July 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7591

This specification defines mechanisms for dynamically registeringOAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.

RFC 7592 OAuth 2.0 Dynamic Client Registration Management Protocol

Authors: J. Richer, Ed., M. Jones, J. Bradley, M. Machulak.

Date: July 2015

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7592

This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods.

RFC 7593 The eduroam Architecture for Network Roaming

Authors: K. Wierenga, S. Winter, T. Wolniewicz.

Date: September 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7593

This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination ofIEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience.

RFC 7594 A Framework for Large-Scale Measurement of Broadband Performance (LMAP)

Authors: P. Eardley, A. Morton, M. Bagnulo, T. Burbridge, P. Aitken, A. Akhter.

Date: September 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7594

Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. This document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of BroadbandPerformance).

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 7596 Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture

Authors: Y. Cui, Q. Sun, M. Boucadair, T. Tsou, Y. Lee, I. Farrer.

Date: July 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7596

Dual-Stack Lite (DS-Lite) (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called "Lightweight 4over6", which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs.

RFC 7597 Mapping of Address and Port with Encapsulation (MAP-E)

Authors: O. Troan, Ed., W. Dec, X. Li, C. Bao, S. Matsushima, T. Murakami, T. Taylor, Ed..

Date: July 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7597

This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports.

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 7599 Mapping of Address and Port using Translation (MAP-T)

Authors: X. Li, C. Bao, W. Dec, Ed., O. Troan, S. Matsushima, T. Murakami.

Date: July 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7599

This document specifies the solution architecture based on "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation(NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network.

RFC 7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)

Authors: R. Despres, S. Jiang, Ed., R. Penno, Y. Lee, G. Chen, M. Chen.

Date: July 2015

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7600

This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offeringIPv4 service to customers. The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end. Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set.

RFC 7601 Message Header Field for Indicating Message Authentication Status

Authors: M. Kucherawy.

Date: August 2015

Formats: txt json html

Obsoletes: RFC 7001, RFC 7410

Obsoleted by: RFC 8601

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7601

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 7602 IS-IS Extended Sequence Number TLV

Authors: U. Chunduri, W. Lu, A. Tian, N. Shen.

Date: July 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7602

This document defines the Extended Sequence Number TLV to protectIntermediate System to Intermediate System (IS-IS) PDUs from replay attacks.

RFC 7603 Energy Management (EMAN) Applicability Statement

Authors: B. Schoening, M. Chandramouli, B. Nordman.

Date: August 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7603

The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to other relevant energy monitoring standards and architectures.

RFC 7604 Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP)

Authors: M. Westerlund, T. Zeng.

Date: September 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7604

This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-Time Streaming Protocol(RTSP). Each technique includes a description of how it would be used, the security implications of using it, and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document.

RFC 7605 Recommendations on Using Assigned Transport Port Numbers

Authors: J. Touch.

Date: August 2015

Formats: txt json html

Also: BCP 0165

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7605

This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA. It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document.It provides guidelines for designers regarding how to interact with the IANA processes defined in RFC 6335, thus serving to complement(but not update) that document.

RFC 7606 Revised Error Handling for BGP UPDATE Messages

Authors: E. Chen, Ed., J. Scudder, Ed., P. Mohapatra, K. Patel.

Date: August 2015

Formats: txt html json

Updates: RFC 1997, RFC 4271, RFC 4360, RFC 4456, RFC 4760, RFC 5543, RFC 5701, RFC 6368

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7606

According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received.This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.
This document updates error handling for RFCs 1997, 4271, 4360, 4456,4760, 5543, 5701, and 6368.

RFC 7607 Codification of AS 0 Processing

Authors: W. Kumari, R. Bush, H. Schiller, K. Patel.

Date: August 2015

Formats: txt html json

Updates: RFC 4271

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7607

This document updates RFC 4271 and proscribes the use of AutonomousSystem (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH,AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message.

RFC 7608 IPv6 Prefix Length Recommendation for Forwarding

Authors: M. Boucadair, A. Petrescu, F. Baker.

Date: July 2015

Formats: txt json html

Also: BCP 0198

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7608

IPv6 prefix length, as in IPv4, is a parameter conveyed and used inIPv6 routing and forwarding processes in accordance with theClassless Inter-domain Routing (CIDR) architecture. The length of anIPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.

RFC 7609 IBM's Shared Memory Communications over RDMA (SMC-R) Protocol

Authors: M. Fox, C. Kassimis, J. Stevens.

Date: August 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7609

This document describes IBM's Shared Memory Communications over RDMA(SMC-R) protocol. This protocol provides Remote Direct Memory Access(RDMA) communications to TCP endpoints in a manner that is transparent to socket applications. It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, as well as transparent high availability and load balancing when redundant RDMA network paths are available. It maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data.

RFC 7610 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers

Authors: F. Gont, W. Liu, G. Van de Velde.

Date: August 2015

Formats: txt json html

Also: BCP 0199

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7610

This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based onDHCPv6 packet filtering at the layer 2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6-Shield.

RFC 7611 BGP ACCEPT_OWN Community Attribute

Authors: J. Uttaro, P. Mohapatra, D. Smith, R. Raszuk, J. Scudder.

Date: August 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7611

Under certain conditions, it is desirable for a Border GatewayProtocol (BGP) route reflector to be able to modify the Route Target(RT) list of a Virtual Private Network (VPN) route that the route reflector distributes, enabling the route reflector to control how a route originated within one VPN Routing and Forwarding table (VRF) is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same Provider Edge(PE) router as the VRF(s) that imports the route. However, due to the constraints of BGP, it does not work if the two are on the samePE. This document describes a modification to BGP allowing this technique to work when the VRFs are on the same PE and to be used in a standard manner throughout an autonomous system.

RFC 7612 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services

Authors: P. Fleming, I. McDonald.

Date: June 2015

Formats: txt html json

Obsoletes: RFC 3712

Status: INFORMATIONAL

DOI: 10.17487/RFC 7612

This document defines a schema, object classes, and attributes, forPrinters and print services, for use with directories that support the Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of "InternetPrinting Protocol/1.1: Model and Semantics" (RFC 2911). AdditionalPrinter attributes are based on definitions in "Printer MIB v2" (RFC3805), "PWG Command Set Format for IEEE 1284 Device ID v1.0" (PWG5107.2), "IPP Job and Printer Extensions - Set 3 (JPS3)" (PWG5100.13), and "IPP Everywhere" (PWG 5100.14).
This memo is an Independent Submission to the RFC Editor by theInternet Printing Protocol (IPP) Working Group of the IEEE-ISTOPrinter Working Group (PWG), as part of their PWG "IPP Everywhere"(PWG 5100.14) project for secure mobile printing with vendor-neutralClient software.
This document obsoletes RFC 3712.

RFC 7613 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords

Authors: P. Saint-Andre, A. Melnikov.

Date: August 2015

Formats: txt html json

Obsoletes: RFC 4013

Obsoleted by: RFC 8265

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7613

This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454).The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC3454, and this document obsoletes RFC 4013.

RFC 7614 Explicit Subscriptions for the REFER Method

Authors: R. Sparks.

Date: August 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7614

The Session Initiation Protocol (SIP) REFER request, as defined byRFC 3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible and complicates avoiding SIP dialog sharing.This document defines extensions to REFER that remove the implicit subscription and, if desired, replace it with an explicit one.

RFC 7615 HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields

Authors: J. Reschke.

Date: September 2015

Formats: txt json html

Obsoletes: RFC 2617

Obsoleted by: RFC 9110

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7615

This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HypertextTransfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted.

RFC 7616 HTTP Digest Access Authentication

Authors: R. Shekh-Yusef, Ed., D. Ahrens, S. Bremer.

Date: September 2015

Formats: txt html json

Obsoletes: RFC 2617

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7616

The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.

RFC 7617 The 'Basic' HTTP Authentication Scheme

Authors: J. Reschke.

Date: September 2015

Formats: txt html json

Obsoletes: RFC 2617

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7617

This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.

RFC 7618 Dynamic Allocation of Shared IPv4 Addresses

Authors: Y. Cui, Q. Sun, I. Farrer, Y. Lee, Q. Sun, M. Boucadair.

Date: August 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7618

This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple active clients simultaneously, with each client being differentiated by a unique set of transport- layer source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described, and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included.
Due to the nature of IP address sharing, some limitations to its applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized.

RFC 7619 The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: V. Smyslov, P. Wouters.

Date: August 2015

Formats: txt json html

Updates: RFC 4301

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7619

This document specifies the NULL Authentication method and theID_NULL Identification Payload ID Type for Internet Key ExchangeProtocol version 2 (IKEv2). This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for OpportunisticSecurity (also known as Opportunistic Encryption) to defend againstPervasive Monitoring attacks without the need to sacrifice anonymity.

RFC 7620 Scenarios with Host Identification Complications

Authors: M. Boucadair, Ed., B. Chatras, T. Reddy, B. Williams, B. Sarikaya.

Date: August 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7620

This document describes a set of scenarios in which complications when identifying which policy to apply for a host are encountered.This problem is abstracted as "host identification". Describing these scenarios allows commonalities between scenarios to be identified, which is helpful during the solution design phase.
This document does not include any solution-specific discussions.

RFC 7621 A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework

Authors: A.B. Roach.

Date: August 2015

Formats: txt json html

Updates: RFC 6665

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7621

Experience since the publication of the most recent SIP Events framework (in July 2012) has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior.
This document updates RFC 6665.

RFC 7622 Extensible Messaging and Presence Protocol (XMPP): Address Format

Authors: P. Saint-Andre.

Date: September 2015

Formats: txt html json

Obsoletes: RFC 6122

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7622

This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122.

RFC 7623 Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)

Authors: A. Sajassi, Ed., S. Salam, N. Bitar, A. Isaac, W. Henderickx.

Date: September 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7623

This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/ClientMAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN.

RFC 7624 Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement

Authors: R. Barnes, B. Schneier, C. Jennings, T. Hardie, B. Trammell, C. Huitema, D. Borkmann.

Date: August 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7624

Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks.

RFC 7625 Architecture of an IP/MPLS Network with Hardened Pipes

Authors: J. T. Hao, P. Maheshwari, R. Huang, L. Andersson, M. Chen.

Date: August 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7625

This document describes an IP/MPLS network that has an infrastructure that can be separated into two or more strata. For the implementation described in this document, the infrastructure has been separated into two strata: one for the "Hard Pipes", called the"Hard Pipe Stratum", and one for the normal IP/MPLS traffic, called the "Normal IP/MPLS Stratum".
This document introduces the concept of a Hard Pipe -- an MPLS LabelSwitched Path (LSP) or a pseudowire (PW) with a bandwidth that is guaranteed and can neither be exceeded nor infringed upon.
The Hard Pipe stratum does not use statistical multiplexing; for theLSPs and PWs set up within this stratum, the bandwidth is guaranteed end to end.
The document does not specify any new protocol or procedures. It does explain how the MPLS standards implementation has been deployed and operated to meet the requirements from operators that offer traditional Virtual Leased Line (VLL) services.

RFC 7626 DNS Privacy Considerations

Authors: S. Bortzmeyer.

Date: August 2015

Formats: txt html json

Obsoleted by: RFC 9076

Status: INFORMATIONAL

DOI: 10.17487/RFC 7626

This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions.

RFC 7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension

Authors: K. Bhargavan, Ed., A. Delignat-Lavaud, A. Pironti, A. Langley, M. Ray.

Date: September 2015

Formats: txt html json

Updates: RFC 5246

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7627

The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.

RFC 7628 A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth

Authors: W. Mills, T. Showalter, H. Tschofenig.

Date: August 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7628

OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf.
This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer(SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols.
Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password.

RFC 7629 Flow-Binding Support for Mobile IP

Authors: S. Gundavelli, Ed., K. Leung, G. Tsirtsis, A. Petrescu.

Date: August 2015

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7629

This specification defines extensions to the Mobile IP protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build a higher aggregated logical pipe with its home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate IP traffic flow policies for binding individual flows with the registered care- of addresses.

RFC 7630 HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3

Authors: J. Merkle, Ed., M. Lochter.

Date: October 2015

Formats: txt json html

Obsoleted by: RFC 7860

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7630

This memo specifies new HMAC-SHA-2 authentication protocols for theUser-based Security Model (USM) for SNMPv3 defined in RFC 3414.

RFC 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 7632 Endpoint Security Posture Assessment: Enterprise Use Cases

Authors: D. Waltermire, D. Harrington.

Date: September 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7632

This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture.

RFC 7633 X.509v3 Transport Layer Security (TLS) Feature Extension

Authors: P. Hallam-Baker.

Date: October 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7633

The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as OnlineCertificate Status Protocol (OCSP) stapling. Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled. This in turn prevents a denial-of-service attack that might otherwise be possible.

RFC 7634 ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec

Authors: Y. Nir.

Date: August 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7634

This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec.

RFC 7635 Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization

Authors: T. Reddy, P. Patil, R. Ravindranath, J. Uberti.

Date: August 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7635

This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities forNAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised.

RFC 7636 Proof Key for Code Exchange by OAuth Public Clients

Authors: N. Sakimura, Ed., J. Bradley, N. Agarwal.

Date: September 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7636

OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange(PKCE, pronounced "pixy").

RFC 7637 NVGRE: Network Virtualization Using Generic Routing Encapsulation

Authors: P. Garg, Ed., Y. Wang, Ed..

Date: September 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7637

This document describes the usage of the Generic RoutingEncapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data-plane aspect of NVGRE.

RFC 7638 JSON Web Key (JWK) Thumbprint

Authors: M. Jones, N. Sakimura.

Date: September 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7638

This specification defines a method for computing a hash value over aJSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint.

RFC 7639 The ALPN HTTP Header Field

Authors: A. Hutton, J. Uberti, M. Thomson.

Date: August 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7639

This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.

RFC 7640 Traffic Management Benchmarking

Authors: B. Constantine, R. Krishnan.

Date: September 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7640

This framework describes a practical methodology for benchmarking the traffic management capabilities of networking devices (i.e., policing, shaping, etc.). The goals are to provide a repeatable test method that objectively compares performance of the device's traffic management capabilities and to specify the means to benchmark traffic management with representative application traffic.

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 7642 System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements

Authors: K. LI, Ed., P. Hunt, B. Khasnabish, A. Nadalin, Z. Zeltsan.

Date: September 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7642

This document provides definitions and an overview of the System forCross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements.

RFC 7643 System for Cross-domain Identity Management: Core Schema

Authors: P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore.

Date: September 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7643

The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP.
This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers.

RFC 7644 System for Cross-domain Identity Management: Protocol

Authors: P. Hunt, Ed., K. Grizzle, M. Ansari, E. Wahlstroem, C. Mortimore.

Date: September 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7644

The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi- domain scenarios easier to support via a standardized service.Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document.

RFC 7645 The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis

Authors: U. Chunduri, A. Tian, W. Lu.

Date: September 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7645

This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in "Keying and Authentication for Routing Protocols (KARP)Design Guidelines" (RFC 6518) for both manual and automated key management protocols.

RFC 7646 Definition and Use of DNSSEC Negative Trust Anchors

Authors: P. Ebersman, W. Kumari, C. Griffiths, J. Livingood, R. Weber.

Date: September 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7646

DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines NegativeTrust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.

RFC 7647 Clarifications for the Use of REFER with RFC 6665

Authors: R. Sparks, A.B. Roach.

Date: September 2015

Formats: txt json html

Updates: RFC 3515

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7647

The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by RFC 6665. This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes.

RFC 7648 Port Control Protocol (PCP) Proxy Function

Authors: S. Perreault, M. Boucadair, R. Penno, D. Wing, S. Cheshire.

Date: September 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7648

This document specifies a new Port Control Protocol (PCP) functional element: the PCP proxy. The PCP proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away.

RFC 7649 The Jabber Scribe Role at IETF Meetings

Authors: P. Saint-Andre, D. York.

Date: September 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7649

During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers are commonly called "Jabber scribes". This document summarizes experience with the Jabber scribe role and provides some suggestions for fulfilling the role at IETF meetings.

RFC 7650 A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)

Authors: J. Jimenez, J. Lopez-Vega, J. Maenpaa, G. Camarillo.

Date: September 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7650

This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). The CoAP Usage provides the functionality to federate Wireless Sensor Networks(WSNs) in a peer-to-peer fashion. The CoAP Usage for RELOAD allowsCoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data. This functionality is implemented in theRELOAD overlay itself, without the use of centralized servers. TheRELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged.

RFC 7651 3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: A. Dodd-Noble, S. Gundavelli, J. Korhonen, F. Baboescu, B. Weis.

Date: September 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7651

This document defines two new configuration attributes for theInternet Key Exchange Protocol version 2 (IKEv2). These attributes can be used for carrying the IPv4 address and IPv6 address of theProxy-Call Session Control Function (P-CSCF). When an IPsec gateway delivers these attributes to an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network.

RFC 7652 Port Control Protocol (PCP) Authentication Mechanism

Authors: M. Cullen, S. Hartman, D. Zhang, T. Reddy.

Date: September 2015

Formats: txt json html

Updates: RFC 6887

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7652

An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address-mapping and port-mapping information on Network Address Translators (NATs) or firewalls to facilitate communication with remote hosts. However, the uncontrolled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases, the client may need to prove that it is authorized to modify, create, or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases.The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices.
This document updates RFC 6887.

RFC 7653 DHCPv6 Active Leasequery

Authors: D. Raghuvanshi, K. Kinnear, D. Kukrety.

Date: October 2015

Formats: txt json html

Updates: RFC 5460

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7653

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings. That mechanism is limited to queries for DHCPv6 binding data updates prior to the time theDHCPv6 server receives the Leasequery request. Continuous update of an external requestor with Leasequery data is sometimes desired.This document expands on the DHCPv6 Leasequery protocol and allows for active transfer of real-time DHCPv6 binding information data viaTCP. This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options.

RFC 7654 Benchmarking Methodology for In-Service Software Upgrade (ISSU)

Authors: S. Banks, F. Calabria, G. Czirjak, R. Machat.

Date: October 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7654

Modern forwarding devices attempt to minimize any control- and data- plane disruptions while performing planned software changes by implementing a technique commonly known as In-Service SoftwareUpgrade (ISSU). This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event.

RFC 7655 RTP Payload Format for G.711.0

Authors: M. Ramalho, Ed., P. Jones, N. Harada, M. Perumal, L. Miao.

Date: November 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7655

This document specifies the Real-time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for theG.711.0 RTP payload format.

RFC 7656 A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources

Authors: J. Lennox, K. Gross, S. Nandakumar, G. Salgueiro, B. Burman, Ed..

Date: November 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7656

The terminology about, and associations among, Real-time TransportProtocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships.

RFC 7657 Differentiated Services (Diffserv) and Real-Time Communication

Authors: D. Black, Ed., P. Jones.

Date: November 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7657

This memo describes the interaction between Differentiated Services(Diffserv) network quality-of-service (QoS) functionality and real- time network communication, including communication based on theReal-time Transport Protocol (RTP). Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs).WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of theseDiffserv aspects for real-time network communication, includingWebRTC.

RFC 7658 Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs)

Authors: S. Perreault, T. Tsou, S. Sivakumar, T. Taylor.

Date: October 2015

Formats: txt html json

Obsoletes: RFC 4008

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7658

This memo deprecates MIB module NAT-MIB, a portion of the ManagementInformation Base (MIB) previously defined in RFC 4008 for devices implementing Network Address Translator (NAT) function. A companion document defines a new version, NATV2-MIB, which responds to deficiencies found in module NAT-MIB and adds new capabilities.
This document obsoletes RFC 4008. All MIB objects specified in RFC4008 are included in this version unchanged with only the STATUS changed to deprecated.

RFC 7659 Definitions of Managed Objects for Network Address Translators (NATs)

Authors: S. Perreault, T. Tsou, S. Sivakumar, T. Taylor.

Date: October 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7659

This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function. The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document. A companion document deprecates all objects in NAT-MIB. NATV2-MIB can be used for the monitoring of NAT instances on a device capable of NAT function. Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN).

RFC 7660 Diameter Congestion and Filter Attributes

Authors: L. Bertz, S. Manning, B. Hirschman.

Date: October 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7660

This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification(ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN, and minimalDiameter filter administration.
RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions, and actions.It, however, does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by theFilter-Rule are congested.
Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g., packets) are not captured by accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition.
The optional attributes defined in this document are forward and backwards compatible with RFC 5777.

RFC 7661 Updating TCP to Support Rate-Limited Traffic

Authors: G. Fairhurst, A. Sathiaseelan, R. Secchi.

Date: October 2015

Formats: txt html json

Obsoletes: RFC 2861

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7661

This document provides a mechanism to address issues that arise whenTCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic usingTCP while also providing an appropriate response if congestion is experienced.
This document also evaluates the Experimental specification of TCPCongestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861.

RFC 7662 OAuth 2.0 Token Introspection

Authors: J. Richer, Ed..

Date: October 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7662

This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of anOAuth 2.0 token and to determine meta-information about this token.OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.

RFC 7663 Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)

Authors: B. Trammell, Ed., M. Kuehlewind, Ed..

Date: October 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7663

The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute ofTechnology (ETH) Zurich hosted the Stack Evolution in a MiddleboxInternet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack. The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators). This document summarizes the contributions to the workshop and provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 7664 Dragonfly Key Exchange

Authors: D. Harkins, Ed..

Date: November 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7664

This document specifies a key exchange using discrete logarithm cryptography that is authenticated using a password or passphrase.It is resistant to active attack, passive attack, and offline dictionary attack. This document is a product of the Crypto ForumResearch Group (CFRG).

RFC 7665 Service Function Chaining (SFC) Architecture

Authors: J. Halpern, Ed., C. Pignataro, Ed..

Date: October 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7665

This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in theIETF. This document does not propose solutions, protocols, or extensions to existing protocols.

RFC 7666 Management Information Base for Virtual Machines Controlled by a Hypervisor

Authors: H. Asai, M. MacFaden, J. Schoenwaelder, K. Shima, T. Tsou.

Date: October 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7666

This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor).

RFC 7667 RTP Topologies

Authors: M. Westerlund, S. Wenger.

Date: November 2015

Formats: txt json html

Obsoletes: RFC 5117

Status: INFORMATIONAL

DOI: 10.17487/RFC 7667

This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP).In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.
This document is updated with additional topologies and replaces RFC5117.

RFC 7668 IPv6 over BLUETOOTH(R) Low Energy

Authors: J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. Shelby, C. Gomez.

Date: October 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7668

Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the BluetoothSpecial Interest Group. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices. The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low- power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless PersonalArea Network (6LoWPAN) techniques.

RFC 7669 Assigning Digital Object Identifiers to RFCs

Authors: J. Levine.

Date: October 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7669

This document describes the way that Digital Object Identifiers(DOIs) are assigned to past and future RFCs. The DOI is a widely used system that assigns unique identifiers to digital documents that can be queried and managed in a consistent fashion.

RFC 7670 Generic Raw Public-Key Support for IKEv2

Authors: T. Kivinen, P. Wouters, H. Tschofenig.

Date: January 2016

Formats: txt html json

Updates: RFC 7296

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7670

The Internet Key Exchange Version 2 (IKEv2) protocol did have support for raw public keys, but it only supported RSA raw public keys. In constrained environments, it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography.This document updates RFC 7296, adding support for other types of raw public keys to IKEv2.

RFC 7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance

Authors: V. Dukhovni, W. Hardaker.

Date: October 2015

Formats: txt html json

Updates: RFC 6698

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7671

This document clarifies and updates the DNS-Based Authentication ofNamed Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records.

RFC 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)

Authors: V. Dukhovni, W. Hardaker.

Date: October 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7672

This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record.Adoption of this protocol enables an incremental transition of theInternet email backbone to one using encrypted and authenticatedTransport Layer Security (TLS).

RFC 7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records

Authors: T. Finch, M. Miller, P. Saint-Andre.

Date: October 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7673

The DNS-Based Authentication of Named Entities (DANE) specification(RFC 6698) describes how to use TLSA resource records secured byDNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC6698. Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records.

RFC 7674 Clarification of the Flowspec Redirect Extended Community

Authors: J. Haas, Ed..

Date: October 2015

Formats: txt html json

Obsoleted by: RFC 8955

Updates: RFC 5575

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7674

This document updates RFC 5575 ("Dissemination of Flow SpecificationRules") to clarify the formatting of the BGP Flowspec RedirectExtended Community.

RFC 7675 Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness

Authors: M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson.

Date: October 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7675

To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.
This document describes a consent mechanism using a new SessionTraversal Utilities for NAT (STUN) usage.

RFC 7676 IPv6 Support for Generic Routing Encapsulation (GRE)

Authors: C. Pignataro, R. Bonica, S. Krishnan.

Date: October 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7676

Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol.Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.
This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.

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 7678 Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions

Authors: C. Zhou, T. Taylor, Q. Sun, M. Boucadair.

Date: October 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7678

During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, Authentication,Authorization, and Accounting (AAA) support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifiesDiameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose.

RFC 7679 A One-Way Delay Metric for IP Performance Metrics (IPPM)

Authors: G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed..

Date: January 2016

Formats: txt html json

Obsoletes: RFC 2679

Also: STD 0081

Status: INTERNET STANDARD

DOI: 10.17487/RFC 7679

This memo defines a metric for one-way delay of packets acrossInternet paths. It builds on notions introduced and discussed in theIP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makesRFC 2679 obsolete.

RFC 7680 A One-Way Loss Metric for IP Performance Metrics (IPPM)

Authors: G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed..

Date: January 2016

Formats: txt html json

Obsoletes: RFC 2680

Also: STD 0082

Status: INTERNET STANDARD

DOI: 10.17487/RFC 7680

This memo defines a metric for one-way loss of packets acrossInternet paths. It builds on notions introduced and discussed in theIP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makesRFC 2680 obsolete.

RFC 7681 Email Exchange of Secondary School Transcripts

Authors: J. Davin.

Date: October 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7681

A common format simplifies exchange of secondary school academic transcripts via electronic mail. Existing standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients. By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice.

RFC 7682 Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration

Authors: D. McPherson, S. Amante, E. Osterweil, L. Blunk, D. Mitchell.

Date: December 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7682

The purpose of this document is to catalog issues that influenced the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day.

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 7684 OSPFv2 Prefix/Link Attribute Advertisement

Authors: P. Psenak, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura, A. Lindem.

Date: November 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7684

OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed- format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible.

RFC 7685 A Transport Layer Security (TLS) ClientHello Padding Extension

Authors: A. Langley.

Date: October 2015

Formats: txt html json

Updates: RFC 5246

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7685

This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size.

RFC 7686 The ".onion" Special-Use Domain Name

Authors: J. Appelbaum, A. Muffett.

Date: October 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7686

This document registers the ".onion" Special-Use Domain Name.

RFC 7687 Report from the Strengthening the Internet (STRINT) Workshop

Authors: S. Farrell, R. Wenning, B. Bos, M. Blanchet, H. Tschofenig.

Date: December 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7687

The Strengthening the Internet (STRINT) workshop assembled one hundred participants in London for two days in early 2014 to discuss how the technical community, and in particular the IETF and the W3C, should react to Pervasive Monitoring and more generally how to strengthen the Internet in the face of such attacks. The discussions covered issues of terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies(including opportunistic encryption), and more. The workshop ended with a few high-level recommendations, that it is believed could be implemented and could help strengthen the Internet. This is the report of that workshop.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 7688 GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks

Authors: Y. Lee, Ed., G. Bernstein, Ed..

Date: November 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7688

This document provides Generalized Multiprotocol Label Switching(GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with WavelengthSwitched Optical Network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all the optical signals in the network are compatible with all network elements participating in the network.
This compatibility constraint model is applicable to common optical or hybrid electro-optical systems such as optical-electronic-optical(OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals.

RFC 7689 Signaling Extensions for Wavelength Switched Optical Networks

Authors: G. Bernstein, Ed., S. Xu, Y. Lee, Ed., G. Martinelli, H. Harai.

Date: November 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7689

This document provides extensions to Generalized Multiprotocol LabelSwitching (GMPLS) signaling for control of Wavelength SwitchedOptical Networks (WSONs). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes.This document provides mechanisms to support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms.

RFC 7690 Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))

Authors: M. Byerly, M. Hite, J. Jaeggli.

Date: January 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7690

This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination(typically the server) in ECMP load-balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures.

RFC 7691 Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members

Authors: S. Bradner, Ed..

Date: November 2015

Formats: txt html json

Obsoleted by: RFC 8711

Updates: RFC 4071

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7691

BCP 101 defines the start and end dates for the terms of IETFAdministrative Oversight Committee (IAOC) members; these terms have proven to be impractical. This memo updates BCP 101 to direct theIAOC to establish more practical start and end dates for terms ofIAOC members.

RFC 7692 Compression Extensions for WebSocket

Authors: T. Yoshino.

Date: December 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7692

This document defines a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of WebSocket data messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method for applying a compression algorithm to the contents of WebSocket messages. Each compression algorithm has to be defined in a document defining the extension by specifying the parameter negotiation and the payload transformation algorithm in detail. This document also specifies one specific compression extension using theDEFLATE algorithm.

RFC 7693 The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)

Authors: M-J. Saarinen, Ed., J-P. Aumasson.

Date: November 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7693

This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures. BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC).

RFC 7694 Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding

Authors: J. Reschke.

Date: November 2015

Formats: txt html json

Obsoleted by: RFC 9110

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7694

In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.
Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate the content codings that are supported in requests.

RFC 7695 Distributed Prefix Assignment Algorithm

Authors: P. Pfister, B. Paterson, J. Arkko.

Date: November 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7695

This document specifies a distributed algorithm for dividing a set of prefixes in a manner that allows for automatic assignment of sub- prefixes that are unique and non-overlapping. Used in conjunction with a protocol that provides flooding of information among a set of participating nodes, prefix configuration within a network may be automated.

RFC 7696 Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms

Authors: R. Housley.

Date: November 2015

Formats: txt json html

Also: BCP 0201

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7696

Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature.Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.

RFC 7697 MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB)

Authors: P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros.

Date: January 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7697

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 to configure theOperations, Administration, and Maintenance (OAM) identifiers forMultiprotocol Label Switching (MPLS) and the MPLS-based TransportProfile (TP).

RFC 7698 Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks

Authors: O. Gonzalez de Dios, Ed., R. Casellas, Ed., F. Zhang, X. Fu, D. Ceccarelli, I. Hussain.

Date: November 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7698

To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International TelecommunicationUnion Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new DenseWavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the"frequency slot". In such an environment, a data-plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid(flexi-grid).
Given the specific characteristics of flexi-grid optical networks and their associated technology, this document defines a framework and the associated control-plane requirements for the application of the existing GMPLS architecture and control-plane protocols to the control of flexi-grid DWDM networks. The actual extensions to theGMPLS protocols will be defined in companion documents.

RFC 7699 Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers

Authors: A. Farrel, D. King, Y. Li, F. Zhang.

Date: November 2015

Formats: txt html json

Updates: RFC 3471, RFC 6205

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7699

GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T StudyGroup 15 has defined a finer-granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid.
This document updates RFCs 3471 and 6205 by introducing a new label format.

RFC 7700 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames

Authors: P. Saint-Andre.

Date: December 2015

Formats: txt html json

Obsoleted by: RFC 8266

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7700

This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames","display names", or "petnames") for people, devices, accounts, websites, and other entities.

RFC 7701 Multi-party Chat Using the Message Session Relay Protocol (MSRP)

Authors: A. Niemi, M. Garcia-Martin, G. Sandbakken.

Date: December 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7701

The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages (IMs) within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and theSession Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP.

RFC 7702 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat

Authors: P. Saint-Andre, S. Ibarra, S. Loreto.

Date: December 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7702

This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multi-party chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP).Specifically, this document defines a mapping between the SIP-basedMessage Session Relay Protocol (MSRP) and the XMPP Multi-User Chat(MUC) extension.

RFC 7703 Experience with Testing of Mapping of Address and Port Using Translation (MAP-T)

Authors: E. Cordeiro, R. Carnier, A. Moreiras.

Date: November 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7703

This document describes the testing result of a network utilizing aMapping of Address and Port using Translation (MAP-T) double translation solution; it provides an overview of user applications' behavior with a shared IPv4 address.
The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines.

RFC 7704 An IETF with Much Diversity and Professional Conduct

Authors: D. Crocker, N. Clark.

Date: November 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7704

The process of producing today's Internet technologies through a culture of open participation and diverse collaboration has proved strikingly efficient and effective, and it is distinctive among standards organizations. During the early years of the IETF and its antecedent, participation was almost entirely composed of a small group of well-funded, American, white, male technicians, demonstrating a distinctive and challenging group dynamic, both in management and in personal interactions. In the case of the IETF, interaction style can often contain singularly aggressive behavior, often including singularly hostile tone and content. Groups with greater diversity make better decisions. Obtaining meaningful diversity requires more than generic good will and statements of principle. Many different behaviors can serve to reduce participant diversity or participation diversity. This document discusses IETF participation in terms of the nature of diversity and practical issues that can increase or decrease it. The document represents the authors' assessments and recommendations, following general discussions of the issues in the IETF.

RFC 7705 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute

Authors: W. George, S. Amante.

Date: November 2015

Formats: txt html json

Updates: RFC 4271

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7705

This document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work.

RFC 7706 Decreasing Access Time to Root Servers by Running One on Loopback

Authors: W. Kumari, P. Hoffman.

Date: November 2015

Formats: txt json html

Obsoleted by: RFC 8806

Status: INFORMATIONAL

DOI: 10.17487/RFC 7706

Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1).This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.

RFC 7707 Network Reconnaissance in IPv6 Networks

Authors: F. Gont, T. Chown.

Date: March 2016

Formats: txt json html

Obsoletes: RFC 5157

Status: INFORMATIONAL

DOI: 10.17487/RFC 7707

IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore,IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address- scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.

RFC 7708 Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator

Authors: T. Nadeau, L. Martini, S. Bryant.

Date: November 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7708

The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW). This document specifies an additional VCCV control channel type to be used with pseudowires that do not use the PW Control Word and that are carried over an MPLS network. This new VCCV CC type uses the Generic Associated ChannelLabel defined in RFC 5586 to distinguish VCCV packets from packets carrying user data. This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations,Administration, and Maintenance (OAM) identification, particularly inMPLS Transport Profile (MPLS-TP) networks (RFC 5921).

RFC 7709 Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs)

Authors: A. Malis, Ed., B. Wilson, G. Clapp, V. Shukla.

Date: November 2015

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7709

Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification),LSP set up delay, quality-of-service differentiation, and different levels of resilience.
The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-ProtocolLabel Switching (GMPLS).

RFC 7710 Captive-Portal Identification Using DHCP or Router Advertisements (RAs)

Authors: W. Kumari, O. Gudmundsson, P. Ebersman, S. Sheng.

Date: December 2015

Formats: txt html json

Obsoleted by: RFC 8910

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7710

In many environments offering short-term or temporary Internet access(such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated.
This document describes a DHCP option (and a Router Advertisement(RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to getInternet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document.

RFC 7711 PKIX over Secure HTTP (POSH)

Authors: M. Miller, P. Saint-Andre.

Date: November 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7711

Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and PresenceProtocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.

RFC 7712 Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)

Authors: P. Saint-Andre, M. Miller, P. Hancke.

Date: November 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7712

This document improves the security of the Extensible Messaging andPresence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains.

RFC 7713 Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements

Authors: M. Mathis, B. Briscoe.

Date: December 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7713

This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ExplicitCongestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases"(RFC 6789), provides the entry point to the set of ConEx documentation.

RFC 7714 AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)

Authors: D. McGrew, K. Igoe.

Date: December 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7714

This document defines how the AES-GCM Authenticated Encryption withAssociated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-timeTransport Protocol (SRTP).

RFC 7715 Multipoint LDP (mLDP) Node Protection

Authors: IJ. Wijnands, Ed., K. Raza, A. Atlas, J. Tantsura, Q. Zhao.

Date: January 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7715

This document describes procedures to support node protection forPoint-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths(P2MP and MP2MP LSPs) that have been built by the Multipoint LabelDistribution Protocol (mLDP). In order to protect a node N, thePoint of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P)Label Switched Paths (LSPs). The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N.

RFC 7716 Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures

Authors: J. Zhang, L. Giuliano, E. Rosen, Ed., K. Subramanian, D. Pacella.

Date: December 2015

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7716

RFCs 6513, 6514, and others describe protocols and procedures that aService Provider (SP) may deploy in order to offer Multicast VirtualPrivate Network (Multicast VPN or MVPN) service to its customers.Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as"Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures forGlobal Table Multicast.

RFC 7717 IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)

Authors: K. Pentikousis, Ed., E. Zhang, Y. Cui.

Date: December 2015

Formats: txt json html

Updates: RFC 4656, RFC 5357

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7717

The One-Way Active Measurement Protocol (OWAMP) and Two-Way ActiveMeasurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP. If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management.

RFC 7718 Registries for the One-Way Active Measurement Protocol (OWAMP)

Authors: A. Morton.

Date: December 2015

Formats: txt html json

Updates: RFC 4656

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7718

This memo describes the registries for OWAMP -- the One-Way ActiveMeasurement Protocol. The registries allow assignment of Mode bit positions and OWAMP Command numbers. Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry. This memo updates RFC 4656.

RFC 7719 DNS Terminology

Authors: P. Hoffman, A. Sullivan, K. Fujiwara.

Date: December 2015

Formats: txt html json

Obsoleted by: RFC 8499

Status: INFORMATIONAL

DOI: 10.17487/RFC 7719

The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.

RFC 7720 DNS Root Name Service Protocol and Deployment Requirements

Authors: M. Blanchet, L-J. Liman.

Date: December 2015

Formats: txt html json

Obsoletes: RFC 2870

Also: BCP 0040

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7720

The DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope.

RFC 7721 Security and Privacy Considerations for IPv6 Address Generation Mechanisms

Authors: A. Cooper, F. Gont, D. Thaler.

Date: March 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7721

This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.

RFC 7722 Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)

Authors: C. Dearlove, T. Clausen.

Date: December 2015

Formats: txt json html

Updates: RFC 7188, RFC 7631

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7722

This specification describes an extension to the Optimized Link StateRouting Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.
This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.

RFC 7723 Port Control Protocol (PCP) Anycast Addresses

Authors: S. Kiesel, R. Penno.

Date: January 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7723

The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-pathNAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses.

RFC 7724 Active DHCPv4 Lease Query

Authors: K. Kinnear, M. Stapp, B. Volz, N. Russell.

Date: December 2015

Formats: txt html json

Updates: RFC 6926

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7724

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388). That mechanism is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient, or even possible.In addition, continuous update of an external requestor withLeasequery data is sometimes desired. This document expands on theDHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP. This document updates RFC 6926, "DHCPv4 Bulk Leasequery".

RFC 7725 An HTTP Status Code to Report Legal Obstacles

Authors: T. Bray.

Date: February 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7725

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.

RFC 7726 Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs)

Authors: V. Govindan, K. Rajaraman, G. Mirsky, N. Akiya, S. Aldrin.

Date: January 2016

Formats: txt json html

Updates: RFC 5884

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7726

This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional ForwardingDetection) sessions for a given <MPLS LSP, FEC&rt; as described in RFC5884.

RFC 7727 Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)

Authors: M. Zhang, H. Wen, J. Hu.

Date: January 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7727

The Inter-Chassis Communication Protocol (ICCP) supports an inter- chassis redundancy mechanism that is used to support high network availability.
In this document, Provider Edge (PE) devices in a Redundancy Group(RG) running ICCP are used to offer multihomed connectivity toSpanning Tree Protocol (STP) networks to improve availability of theSTP networks. The ICCP TLVs and usage for the ICCP STP application are defined.

RFC 7728 RTP Stream Pause and Resume

Authors: B. Burman, A. Akram, R. Even, M. Westerlund.

Date: February 2016

Formats: txt html json

Updates: RFC 5104

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7728

With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport. This document extends the Codec Control Message(CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104.

RFC 7729 Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management

Authors: B. Khasnabish, E. Haleplidis, J. Hadi Salim, Ed..

Date: December 2015

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7729

Deployment experience has demonstrated the value of using theForwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, theForwarding Element Manager (FEM) is modeled by creating a LogicalFunctional Block (LFB) to represent its functionality. We refer to this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element(CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB. This document introduces the SM LFB class, an LFB class that specifies the configuration parameters of an FE. The configuration parameters include new LFB class loading and CE associations; they also provide manipulation of debug mechanisms along with a general purpose attribute definition to describe configuration information.

RFC 7730 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator

Authors: G. Huston, S. Weiler, G. Michaelson, S. Kent.

Date: January 2016

Formats: txt html json

Obsoletes: RFC 6490

Obsoleted by: RFC 8630

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7730

This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL.

RFC 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL)

Authors: J. Hui, R. Kelsey.

Date: February 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7731

This document specifies the Multicast Protocol for Low-Power andLossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPLForwarders in an MPL Domain.
MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency.

RFC 7732 Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL)

Authors: P. van der Stok, R. Cragie.

Date: February 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7732

The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks(MPL) multicast messages with Admin-Local scope in a border router.

RFC 7733 Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control

Authors: A. Brandt, E. Baccelli, R. Cragie, P. van der Stok.

Date: February 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7733

The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power andLossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.

RFC 7734 Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN)

Authors: D. Allan, Ed., J. Tantsura, D. Fedyk, A. Sajassi.

Date: January 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7734

This document describes how Ethernet Shortest Path Bridging MAC mode(SPBM) can be combined with Ethernet VPN (EVPN) to interwork withProvider Backbone Bridging Provider Edges (PBB PEs) as described in the PBB-EVPN solution (RFC 7623). This is achieved via operational isolation of each Ethernet network attached to an EVPN core while supporting full interworking between the different variations ofEthernet networks.

RFC 7735 Tracking Reviews of Documents

Authors: R. Sparks, T. Kivinen.

Date: January 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7735

Several review teams ensure specific types of review are performed onInternet-Drafts as they progress towards becoming RFCs. The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker. This document discusses requirements for improving those tools without disrupting current work flows.

RFC 7736 Content Delivery Network Interconnection (CDNI) Media Type Registration

Authors: K. Ma.

Date: December 2015

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7736

This document defines the standard media type used by the ContentDelivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter.

RFC 7737 Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification

Authors: N. Akiya, G. Swallow, C. Pignataro, L. Andersson, M. Chen.

Date: January 2016

Formats: txt json html

Updates: RFC 7110

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7737

The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode. The value of thisReply Mode is 5. The update creates a simple way to indicate that the reverse LSP should be used as the return path. This document also adds an optional TLV that can carry an ordered list of ReplyMode values.
This document updates RFC 7110.

RFC 7738 A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)

Authors: M. Blanchet, A. Schiltknecht, P. Shames.

Date: January 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7738

This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS).

RFC 7739 Security Implications of Predictable Fragment Identification Values

Authors: F. Gont.

Date: February 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7739

IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host.The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.

RFC 7740 Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication

Authors: Z. Zhang, Y. Rekhter, A. Dolganow.

Date: January 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7740

RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies how a partial mesh of MP2MP tunnels can be simulated using IngressReplication. This solution enables a service provider to use IngressReplication to offer transparent bidirectional multicast service to its VPN customers.

RFC 7741 RTP Payload Format for VP8 Video

Authors: P. Westin, H. Lundin, M. Glover, J. Uberti, F. Galligan.

Date: March 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7741

This memo describes an RTP payload format for the VP8 video codec.The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences.

RFC 7742 WebRTC Video Processing and Codec Requirements

Authors: A.B. Roach.

Date: March 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7742

This specification provides the requirements and considerations forWebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters.

RFC 7743 Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping

Authors: J. Luo, Ed., L. Jin, Ed., T. Nadeau, Ed., G. Swallow, Ed..

Date: January 2016

Formats: txt html json

Updates: RFC 4379

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7743

In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping andTraceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379.

RFC 7744 Use Cases for Authentication and Authorization in Constrained Environments

Authors: L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S. Kumar.

Date: January 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7744

Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.
This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.
Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally.

RFC 7745 XML Schemas for Reverse DNS Management

Authors: T. Manderson.

Date: January 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7745

This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational StateTransfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since2011 and is being used by the registries responsible for reverse DNS(rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through anHTTPS transaction that is mediated by an X.509 certificate.

RFC 7746 Label Switched Path (LSP) Self-Ping

Authors: R. Bonica, I. Minei, M. Conn, D. Pacella, L. Tomotaki.

Date: January 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7746

When certain RSVP-TE optimizations are implemented, ingress LabelSwitching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes.According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives aRESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.
This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes.
LSP Self-ping is a new protocol. It is not an extension of LSP Ping.Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.
LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.

RFC 7747 Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence

Authors: R. Papneja, B. Parise, S. Hares, D. Lee, I. Varlashkin.

Date: April 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7747

BGP is widely deployed and used by several service providers as the default inter-AS (Autonomous System) routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP benchmarking methodology using existing BGP convergence terminology as defined in RFC 4098.

RFC 7748 Elliptic Curves for Security

Authors: A. Langley, M. Hamburg, S. Turner.

Date: January 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7748

This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.

RFC 7749 The "xml2rfc" Version 2 Vocabulary

Authors: J. Reschke.

Date: February 2016

Formats: txt json html

Obsoletes: RFC 2629

Obsoleted by: RFC 7991

Status: INFORMATIONAL

DOI: 10.17487/RFC 7749

This document defines the "xml2rfc" version 2 vocabulary: an XML- based language used for writing RFCs and Internet-Drafts.
Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014.
This document obsoletes RFC 2629.

RFC 7750 Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)

Authors: J. Hedin, G. Mirsky, S. Baillargeon.

Date: February 2016

Formats: txt json html

Updates: RFC 5357

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7750

This document describes an optional extension for Two-Way ActiveMeasurement Protocol (TWAMP) allowing the monitoring of theDifferentiated Service Code Point and Explicit CongestionNotification fields with the TWAMP-Test protocol.

RFC 7751 Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)

Authors: S. Sorce, T. Yu.

Date: March 2016

Formats: txt json html

Updates: RFC 4120

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7751

This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED. It allows for multiple MessageAuthentication Codes (MACs) or signatures to authenticate the contained authorization data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container.This document updates RFC 4120.

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 7753 Port Control Protocol (PCP) Extension for Port-Set Allocation

Authors: Q. Sun, M. Boucadair, S. Sivakumar, C. Zhou, T. Tsou, S. Perreault.

Date: February 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7753

In some use cases, e.g., Lightweight 4over6, the client may require not just one port, but a port set. This document defines an extension to the Port Control Protocol (PCP) that allows clients to manipulate a set of ports as a whole. This is accomplished using a new MAP option: PORT_SET.

RFC 7754 Technical Considerations for Internet Service Blocking and Filtering

Authors: R. Barnes, A. Cooper, O. Kolkman, D. Thaler, E. Nordmark.

Date: March 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7754

The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on"blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with theInternet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.

RFC 7755 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments

Authors: T. Anderson.

Date: February 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7755

This document describes the use of the Stateless IP/ICMP TranslationAlgorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on theInternet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses.This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses.
The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity.

RFC 7756 Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode

Authors: T. Anderson, S. Steffann.

Date: February 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7756

This document describes an extension of the Stateless IP/ICMPTranslation for IPv6 Internet Data Center Environments (SIIT-DC) architecture, which allows applications, protocols, or nodes that are incompatible with IPv6 and/or Network Address Translation to operate correctly with SIIT-DC. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency.
The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755.

RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation

Authors: T. Anderson, A. Leiva Popper.

Date: February 2016

Formats: txt html json

Updates: RFC 6145

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7757

This document extends the Stateless IP/ICMP Translation Algorithm(SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4.

RFC 7758 Time Capability in NETCONF

Authors: T. Mizrahi, Y. Moses.

Date: February 2016

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7758

This document defines a capability-based extension to the NetworkConfiguration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allowsNETCONF clients to invoke configuration updates according to scheduled times and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients.

RFC 7759 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping

Authors: E. Bellagamba, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward, J. Drake.

Date: February 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7759

This specification describes the configuration of proactive MPLS-TPOperations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the LSP Ping protocol.

RFC 7760 Statement of Work for Extensions to the IETF Datatracker for Author Statistics

Authors: R. Housley.

Date: January 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7760

This is the Statement of Work (SOW) for extensions to the IETFDatatracker to provide statistics about RFCs and Internet-Drafts and their authors.

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 7762 Initial Assignment for the Content Security Policy Directives Registry

Authors: M. West.

Date: January 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7762

This document establishes an Internet Assigned Number Authority(IANA) registry for Content Security Policy directives and populates that registry with the directives defined in the Content SecurityPolicy Level 2 specification.

RFC 7763 The text/markdown Media Type

Authors: S. Leonard.

Date: March 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7763

This document registers the text/markdown media type for use withMarkdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.

RFC 7764 Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations

Authors: S. Leonard.

Date: March 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7764

This document elaborates upon the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.Background information, local storage strategies, and additional syntax registrations are supplied.

RFC 7765 TCP and Stream Control Transmission Protocol (SCTP) RTO Restart

Authors: P. Hurtig, A. Brunstrom, A. Petlund, M. Welzl.

Date: February 2016

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7765

This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short lived or application limited.

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 7767 Application-Initiated Check-Pointing via the Port Control Protocol (PCP)

Authors: S. Vinapamula, S. Sivakumar, M. Boucadair, T. Reddy.

Date: February 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7767

This document specifies a mechanism for a host to indicate via thePort Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side.
This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed.

RFC 7768 Port Management to Reduce Logging in Large-Scale NATs

Authors: T. Tsou, W. Li, T. Taylor, J. Huang.

Date: January 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7768

Various IPv6 transition strategies require the introduction of large- scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete.There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address.One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs.This document suggests a way to achieve dynamic port sharing while keeping log volumes low.

RFC 7769 Media Access Control (MAC) Address Withdrawal over Static Pseudowire

Authors: S. Sivabalan, S. Boutros, H. Shah, S. Aldrin, M. Venkatesan.

Date: February 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7769

This document specifies a mechanism to signal Media Access Control(MAC) address withdrawal notification using a pseudowire (PW)Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in a Virtual Private LANService (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment.

RFC 7770 Extensions to OSPF for Advertising Optional Router Capabilities

Authors: A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer.

Date: February 2016

Formats: txt json html

Obsoletes: RFC 4970

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7770

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 andOSPFv3 for advertising optional router capabilities. The RouterInformation (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an OpaqueLSA type ID. In OSPFv3, the RI LSA will be implemented with a uniqueLSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.

RFC 7771 Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires

Authors: A. Malis, Ed., L. Andersson, H. van Helvoort, J. Shin, L. Wang, A. D'Alessandro.

Date: January 2016

Formats: txt json html

Updates: RFC 6870

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7771

In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection.With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures viaMPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of theSwitching Provider Edge Routers (S-PEs) along the path of the MS-PW.This document describes how to achieve this protection via redundantMS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection.

RFC 7772 Reducing Energy Consumption of Router Advertisements

Authors: A. Yourtchenko, L. Colitti.

Date: February 2016

Formats: txt html json

Also: BCP 0202

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7772

Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact.

RFC 7773 Authentication Context Certificate Extension

Authors: S. Santesson.

Date: March 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7773

This document defines an extension to X.509 certificates. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority that issued the certificate in which this extension appears.
This document also defines one data structure for inclusion in this extension. The data structure is designed to hold information when the subject is authenticated using a Security Assertion MarkupLanguage (SAML) assertion.

RFC 7774 Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6

Authors: Y. Doi, M. Gillmore.

Date: March 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7774

This document defines a way to configure a parameter set for MPL(Multicast Protocol for Low-Power and Lossy Networks) via a DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL Forwarder in anMPL Domain. Using the MPL Parameter Configuration Option defined in this document, a network can easily be configured with a single set of MPL parameters.

RFC 7775 IS-IS Route Preference for Extended IP and IPv6 Reachability

Authors: L. Ginsberg, S. Litkowski, S. Previdi.

Date: February 2016

Formats: txt json html

Updates: RFC 5308

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7775

In existing specifications, the route preferences for IPv4/IPv6Extended Reachability TLVs are not explicitly stated. There are also inconsistencies in the definition of how the up/down bit applies to route preference when the prefix advertisement appears in Level 2Link State Protocol Data Units (LSPs). This document addresses these issues.
This document updates RFC 5308.

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 7777 Advertising Node Administrative Tags in OSPF

Authors: S. Hegde, R. Shakir, A. Smirnov, Z. Li, B. Decraene.

Date: March 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7777

This document describes an extension to the OSPF protocol to add an optional operational capability that allows tagging and grouping of the nodes in an OSPF domain. This allows simplification, ease of management and control over route and path selection based on configured policies. This document describes an extension to theOSPF protocol to advertise node administrative tags. The node tags can be used to express and apply locally defined network policies, which are a very useful operational capability. Node tags may be used by either OSPF itself or other applications consuming information propagated via OSPF.
This document describes the protocol extensions to disseminate node administrative tags to the OSPFv2 and OSPFv3 protocol. It provides example use cases of administrative node tags.

RFC 7778 Mobile Communication Congestion Exposure Scenario

Authors: D. Kutscher, F. Mir, R. Winter, S. Krishnan, Y. Zhang, CJ. Bernardos.

Date: March 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7778

This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPPEvolved Packet System (EPS). This memo provides a brief overview of the architecture of these networks (both access and core networks) and current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this discussion, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks.

RFC 7779 Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)

Authors: H. Rogge, E. Baccelli.

Date: April 2016

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7779

This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2).

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 7781 Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access

Authors: H. Zhai, T. Senevirathne, R. Perlman, M. Zhang, Y. Li.

Date: February 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7781

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edgeRBridge (Routing Bridge, or TRILL switch) group providing active- active access to such an end station is represented as a virtualRBridge. Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active- active access by such end stations.

RFC 7782 Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments

Authors: M. Zhang, R. Perlman, H. Zhai, M. Durrani, S. Gupta.

Date: February 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7782

TRILL (Transparent Interconnection of Lots of Links) active-active service provides end stations with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379.
This document specifies a method by which member RBridges (also referred to as Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges (who are not in the group) will see one hostMedia Access Control (MAC) address being associated with the multipleRBridges in the group. Such remote edge RBridges are required to maintain all those associations (i.e., MAC attachments) and to not flip-flop among them (as would occur prior to the implementation of this specification). The design goals of this specification are discussed herein.

RFC 7783 Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)

Authors: T. Senevirathne, J. Pathangi, J. Hudson.

Date: February 2016

Formats: txt html json

Updates: RFC 6325

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7783

TRILL (Transparent Interconnection of Lots of Links) facilitates loop-free connectivity to non-TRILL networks via a choice of anAppointed Forwarder for a set of VLANs. Appointed Forwarders provideVLAN-based load sharing with an active-standby model. High- performance applications require an active-active load-sharing model.The active-active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtualRBridge (also referred to as a virtual Routing Bridge or virtualTRILL switch). Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF(Reverse Path Forwarding) check calculations. This document specifies required enhancements to build Coordinated Multicast Trees(CMT) within the TRILL campus to solve related RPF issues. CMT, which only requires a software upgrade, provides flexibility toRBridges in selecting a desired path of association to a given TRILL multi-destination distribution tree. This document updates RFC 6325.

RFC 7784 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB

Authors: D. Kumar, S. Salam, T. Senevirathne.

Date: February 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7784

This document specifies the MIB for the OAM (Operations,Administration, and Maintenance) objects for IETF TRILL (TransparentInterconnection of Lots of Links).

RFC 7785 Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite

Authors: S. Vinapamula, M. Boucadair.

Date: February 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7785

This document discusses issues induced by the change of the Dual-Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues.

RFC 7786 TCP Modifications for Congestion Exposure (ConEx)

Authors: M. Kuehlewind, Ed., R. Scheffenegger.

Date: May 2016

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7786

Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission ControlProtocol (TCP).

RFC 7787 Distributed Node Consensus Protocol

Authors: M. Stenberg, S. Barth.

Date: April 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7787

This document describes the Distributed Node Consensus Protocol(DNCP), a generic state synchronization protocol that uses theTrickle algorithm and hash trees. DNCP is an abstract protocol and must be combined with a specific profile to make a complete implementable protocol.

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 7789 Impact of BGP Filtering on Inter-Domain Routing Policies

Authors: C. Cardona, P. Francois, P. Lucente.

Date: April 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7789

This document describes how unexpected traffic flows can emerge across an autonomous system as the result of other autonomous systems filtering or restricting the propagation of more-specific prefixes.We provide a review of the techniques to detect the occurrence of this issue and defend against it.

RFC 7790 Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS)

Authors: Y. Yoneya, T. Nemoto.

Date: February 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7790

The framework for the preparation, enforcement, and comparison of internationalized strings (PRECIS) defines several classes of strings for use in application protocols. Because many protocols perform case-sensitive or case-insensitive string comparison, it is necessary to define methods for case mapping. In addition, both theInternationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describe mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other special characters that can be taken into consideration. This document provides guidelines for designers ofPRECIS profiles and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. In particular, this document describes both locale-dependent and context-depending case mappings as well as additional mappings for delimiters and special characters.

RFC 7791 Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: D. Migault, Ed., V. Smyslov.

Date: March 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7791

This document considers a VPN end user establishing an IPsec SecurityAssociation (SA) with a Security Gateway using the Internet KeyExchange Protocol version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address.
The protocol described allows a peer to clone an IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKESA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster node.

RFC 7792 RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks

Authors: F. Zhang, X. Zhang, A. Farrel, O. Gonzalez de Dios, D. Ceccarelli.

Date: March 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7792

This memo describes the extensions to the Resource ReservationProtocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid.

RFC 7793 Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry

Authors: M. Andrews.

Date: May 2016

Formats: txt html json

Also: BCP 0163

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7793

RFC 6598 specifies that "Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure."
This document formally directs IANA to add the associated zones to the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries from accidentally leaking to the global DNS infrastructure.

RFC 7794 IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability

Authors: L. Ginsberg, Ed., B. Decraene, S. Previdi, X. Xu, U. Chunduri.

Date: March 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7794

This document introduces new sub-TLVs to support advertisement ofIPv4 and IPv6 prefix attribute flags and the source router ID of the router that originated a prefix advertisement.

RFC 7795 Pseudowire Redundancy on the Switching Provider Edge (S-PE)

Authors: J. Dong, H. Wang.

Date: February 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7795

This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which pseudowire redundancy is provided on the SwitchingProvider Edge (S-PE) as defined in RFC 5659. Operations of the S-PEs that provide PW redundancy are specified in this document. Signaling of the Preferential Forwarding status as defined in RFCs 6870 and6478 is reused. This document does not require any change to theTerminating Provider Edges (T-PEs) of MS-PW.

RFC 7796 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)

Authors: Y. Jiang, Ed., L. Yong, M. Paul.

Date: March 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7796

This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), which carry the VLAN indicating the E-Tree attribute. The MAC address-based Ethernet forwarding engine and the PW work in the same way as specified in RFC 4762 and RFC 4448, respectively. A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation.

RFC 7797 JSON Web Signature (JWS) Unencoded Payload Option

Authors: M. Jones.

Date: February 2016

Formats: txt html json

Updates: RFC 7519

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7797

JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.
This specification updates RFC 7519 by stating that JSON Web Tokens(JWTs) MUST NOT use the unencoded payload option defined by this specification.

RFC 7798 RTP Payload Format for High Efficiency Video Coding (HEVC)

Authors: Y.-K. Wang, Y. Sanchez, T. Schierl, S. Wenger, M. M. Hannuksela.

Date: March 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7798

This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC InternationalStandard 23008-2, both also known as High Efficiency Video Coding(HEVC) and developed by the Joint Collaborative Team on Video Coding(JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets.Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.

RFC 7799 Active and Passive Metrics and Methods (with Hybrid Types In-Between)

Authors: A. Morton.

Date: May 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7799

This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.

RFC 7800 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

Authors: M. Jones, J. Bradley, H. Tschofenig.

Date: April 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7800

This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.

RFC 7801 GOST R 34.12-2015: Block Cipher "Kuznyechik"

Authors: V. Dolmatov, Ed..

Date: March 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7801

This document is intended to be a source of information about theRussian Federal standard GOST R 34.12-2015 describing the block cipher with a block length of n=128 bits and a key length of k=256 bits, which is also referred to as "Kuznyechik". This algorithm is one of the set of Russian cryptographic standard algorithms (calledGOST algorithms).

RFC 7802 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism

Authors: S. Emery, N. Williams.

Date: March 2016

Formats: txt json html

Obsoletes: RFC 4402

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7802

This document defines the Pseudo-Random Function (PRF) for theKerberos V mechanism for the Generic Security Service ApplicationProgram Interface (GSS-API), based on the PRF defined for theKerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context.
This document obsoletes RFC 4402 and reclassifies that document asHistoric. RFC 4402 starts the PRF+ counter at 1; however, a number of implementations start the counter at 0. As a result, the original specification would not be interoperable with existing implementations.

RFC 7803 Changing the Registration Policy for the NETCONF Capability URNs Registry

Authors: B. Leiba.

Date: February 2016

Formats: txt json html

Updates: RFC 6241

Also: BCP 0203

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7803

The registration policy for the "Network Configuration Protocol(NETCONF) Capability URNs" registry, set up by RFC 6241, has turned out to be unnecessarily strict. This document changes that registration policy to "IETF Review", allowing registrations from certain well-reviewed Experimental RFCs, in addition to StandardsTrack RFCs.

RFC 7804 Salted Challenge Response HTTP Authentication Mechanism

Authors: A. Melnikov.

Date: March 2016

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7804

This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response AuthenticationMechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport LayerSecurity (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.

RFC 7805 Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status

Authors: A. Zimmermann, W. Eddy, L. Eggert.

Date: April 2016

Formats: txt html json

Obsoletes: RFC 0675, RFC 0721, RFC 0761, RFC 0813, RFC 0816, RFC 0879, RFC 0896, RFC 1078, RFC 6013

Updates: RFC 7414

Status: INFORMATIONAL

DOI: 10.17487/RFC 7805

This document reclassifies several TCP extensions and TCP-related documents that either have been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected documents are RFCs 675, 721, 761, 813, 816,879, 896, 1078, and 6013. Additionally, this document reclassifiesRFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status.

RFC 7806 On Queuing, Marking, and Dropping

Authors: F. Baker, R. Pan.

Date: April 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7806

This note discusses queuing and marking/dropping algorithms. While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior.

RFC 7807 Problem Details for HTTP APIs

Authors: M. Nottingham, E. Wilde.

Date: March 2016

Formats: txt json html

Obsoleted by: RFC 9457

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7807

This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.

RFC 7808 Time Zone Data Distribution Service

Authors: M. Douglass, C. Daboo.

Date: March 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7808

This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems.

RFC 7809 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference

Authors: C. Daboo.

Date: March 2016

Formats: txt html json

Updates: RFC 4791

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7809

This document defines an update to the Calendaring Extensions toWebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients and servers to exchange iCalendar data without the need to send full time zone data.

RFC 7810 IS-IS Traffic Engineering (TE) Metric Extensions

Authors: S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu.

Date: May 2016

Formats: txt html json

Obsoleted by: RFC 8570

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7810

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.
This document describes extensions to IS-IS Traffic EngineeringExtensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.
Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.

RFC 7811 An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)

Authors: G. Enyedi, A. Csaszar, A. Atlas, C. Bowers, A. Gopalan.

Date: June 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7811

This document supports the solution put forth in "An Architecture forIP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"(RFC 7812) by defining the associated MRT Lowpoint algorithm that is used in the Default MRT Profile to compute both the necessaryMaximally Redundant Trees with their associated next hops and the alternates to select for MRT-FRR.

RFC 7812 An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)

Authors: A. Atlas, C. Bowers, G. Enyedi.

Date: June 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7812

This document defines the architecture for IP and LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure.

RFC 7813 IS-IS Path Control and Reservation

Authors: J. Farkas, Ed., N. Bragg, P. Unbehagen, G. Parsons, P. Ashwood-Smith, C. Bowers.

Date: June 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7813

IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest PathBridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR.

RFC 7814 Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution

Authors: X. Xu, C. Jacquenet, R. Raszuk, T. Boyes, B. Fee.

Date: March 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7814

This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as "Virtual Subnet", which can be used for building Layer 3 network virtualization overlays within and/or between data centers.

RFC 7815 Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation

Authors: T. Kivinen.

Date: March 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7815

This document describes a minimal initiator version of the InternetKey Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other.
This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description.

RFC 7816 DNS Query Name Minimisation to Improve Privacy

Authors: S. Bortzmeyer.

Date: March 2016

Formats: txt json html

Obsoleted by: RFC 9156

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7816

This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server.

RFC 7817 Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols

Authors: A. Melnikov.

Date: March 2016

Formats: txt json html

Updates: RFC 2595, RFC 3207, RFC 3501, RFC 5804

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7817

This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, andManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLSCommand) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.

RFC 7818 URN Namespace for MEF Documents

Authors: M. Jethanandani.

Date: March 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7818

This document describes the Namespace Identifier (NID) "mef" forUniform Resource Names (URNs) used to identify resources published byMEF Forum (https://www.mef.net). MEF specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of theMEF Assigned Names and Numbers (MANN) registry.

RFC 7819 Privacy Considerations for DHCP

Authors: S. Jiang, S. Krishnan, T. Mrugalski.

Date: April 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7819

DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues.

RFC 7820 UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)

Authors: T. Mizrahi.

Date: March 2016

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7820

The One-Way Active Measurement Protocol (OWAMP) and the Two-WayActive Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDPChecksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as aChecksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDPChecksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.

RFC 7821 UDP Checksum Complement in the Network Time Protocol (NTP)

Authors: T. Mizrahi.

Date: March 2016

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7821

The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations.

RFC 7822 Network Time Protocol Version 4 (NTPv4) Extension Fields

Authors: T. Mizrahi, D. Mayer.

Date: March 2016

Formats: txt json html

Updates: RFC 5905

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7822

The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes(MACs).

RFC 7823 Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions

Authors: A. Atlas, J. Drake, S. Giacalone, S. Previdi.

Date: May 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7823

In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TELabel Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections.

RFC 7824 Privacy Considerations for DHCPv6

Authors: S. Krishnan, T. Mrugalski, S. Jiang.

Date: May 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7824

DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document describes the privacy issues associated with the use of DHCPv6 by Internet users.It is intended to be an analysis of the present situation and does not propose any solutions.

RFC 7825 A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)

Authors: J. Goldberg, M. Westerlund, T. Zeng.

Date: December 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7825

This document defines a solution for Network Address Translation(NAT) traversal for datagram-based media streams set up and controlled with the Real-Time Streaming Protocol version 2 (RTSP2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures.

RFC 7826 Real-Time Streaming Protocol Version 2.0

Authors: H. Schulzrinne, A. Rao, R. Lanphier, M. Westerlund, M. Stiemerling, Ed..

Date: December 2016

Formats: txt json html

Obsoletes: RFC 2326

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7826

This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.
RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).

RFC 7827 The Role of the IRTF Chair

Authors: L. Eggert.

Date: March 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7827

This document briefly describes the role of the Chair of the InternetResearch Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have.

RFC 7828 The edns-tcp-keepalive EDNS0 Option

Authors: P. Wouters, J. Abley, S. Dickinson, R. Bellis.

Date: April 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7828

DNS messages between clients and servers may be received over eitherUDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally,UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.
This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.

RFC 7829 SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol

Authors: Y. Nishida, P. Natarajan, A. Caro, P. Amer, K. Nielsen.

Date: April 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7829

The Stream Control Transmission Protocol (SCTP) supports multihoming.However, when the failover operation specified in RFC 4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. This document specifies a quick failover algorithm and introduces the SCTP Potentially Failed(SCTP-PF) destination state in SCTP Path Management.
This document also specifies a dormant state operation of SCTP that is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard SCTP implementation, as described in RFC 4960.
Additionally, this document introduces an alternative switchback operation mode called "Primary Path Switchover" that will be beneficial in certain situations. This mode of operation applies to both a standard SCTP implementation and an SCTP-PF implementation.
The procedures defined in the document require only minimal modifications to the specification in RFC 4960. The procedures are sender-side only and do not impact the SCTP receiver.

RFC 7830 The EDNS(0) Padding Option

Authors: A. Mayrhofer.

Date: May 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7830

This document specifies the EDNS(0) "Padding" option, which allowsDNS clients and servers to pad request and response messages by a variable number of octets.

RFC 7831 Application Bridging for Federated Access Beyond Web (ABFAB) Architecture

Authors: J. Howlett, S. Hartman, H. Tschofenig, J. Schaad.

Date: May 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7831

Over the last decade, a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access.However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common.
This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote AuthenticationDial-In User Service (RADIUS), the Generic Security ServiceApplication Program Interface (GSS-API), the ExtensibleAuthentication Protocol (EAP), and the Security Assertion MarkupLanguage (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of Identity Providers, RelyingParties, and federations.

RFC 7832 Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases

Authors: R. Smith, Ed..

Date: May 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7832

Federated identity is typically associated with web-based services at present, but there is growing interest in its application in non-web- based contexts. The goal of this memo is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ApplicationBridging for Federated Access Beyond web (ABFAB) architecture and specifications.

RFC 7833 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)

Authors: J. Howlett, S. Hartman, A. Perez-Mendez, Ed..

Date: May 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7833

This document describes the use of the Security Assertion MarkupLanguage (SAML) with RADIUS in the context of the ApplicationBridging for Federated Access Beyond web (ABFAB) architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. TheRADIUS attributes permit encapsulation of SAML Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertionQuery/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients). These clients may be named using a Network Access Identifier (NAI) name identifier format.Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. The use of the artifacts defined in this document is not exclusive to ABFAB. They can be applied in any Authentication, Authorization, and Accounting(AAA) scenario, such as network access control.

RFC 7834 Locator/ID Separation Protocol (LISP) Impact

Authors: D. Saucez, L. Iannone, A. Cabellos, F. Coras.

Date: April 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7834

The Locator/ID Separation Protocol (LISP) aims to improve theInternet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment ofLISP can have on both the routing infrastructure and the end user.

RFC 7835 Locator/ID Separation Protocol (LISP) Threat Analysis

Authors: D. Saucez, L. Iannone, O. Bonaventure.

Date: April 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7835

This document provides a threat analysis of the Locator/ID SeparationProtocol (LISP).

RFC 7836 Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012

Authors: S. Smyshlyaev, Ed., E. Alekseev, I. Oshkin, V. Popov, S. Leontiev, V. Podobaev, D. Belyavsky.

Date: March 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7836

The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standardsGOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.
These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions.

RFC 7837 IPv6 Destination Option for Congestion Exposure (ConEx)

Authors: S. Krishnan, M. Kuehlewind, B. Briscoe, C. Ralli.

Date: May 2016

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7837

Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams.

RFC 7838 HTTP Alternative Services

Authors: M. Nottingham, P. McManus, J. Reschke.

Date: April 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7838

This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.

RFC 7839 Access-Network-Identifier Option in DHCP

Authors: S. Bhandari, S. Gundavelli, M. Grayson, B. Volz, J. Korhonen.

Date: June 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7839

This document specifies the format and mechanism that is to be used for encoding Access-Network Identifiers in DHCPv4 and DHCPv6 messages by defining new Access-Network-Identifier options and sub-options.

RFC 7840 A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol

Authors: J. Winterbottom, H. Tschofenig, L. Liess.

Date: May 2016

Formats: txt json html

Updates: RFC 5985, RFC 6881

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7840

For cases where location servers have access to emergency routing information, they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HTTP-Enabled Location Delivery (HELD) protocol that updates RFC 5985 to support this function. Allowing location and routing information to be acquired in a single request response exchange updates RFC 6881, as current location acquisition and route determination procedures are separate operations.

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 7842 Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool

Authors: R. Sparks.

Date: April 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7842

The web-based IETF email archive search tool based on the requirements captured in RFC 6778 was deployed in January 2014. This memo captures the requirements for a set of improvements that have been identified during its initial years of community use.

RFC 7843 Port Control Protocol (PCP) Third-Party ID Option

Authors: A. Ripke, R. Winter, T. Dietz, J. Quittek, R. da Silva.

Date: May 2016

Formats: txt html json

Updates: RFC 6887

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7843

This document describes a new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option. It is designed to be used together with the THIRD_PARTY option specified in RFC 6887.
The THIRD_PARTY_ID option serves to identify a third party in situations where a third party's IP address contained in theTHIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device.

RFC 7844 Anonymity Profiles for DHCP Clients

Authors: C. Huitema, T. Mrugalski, S. Krishnan.

Date: May 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7844

Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profiles are designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.

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 7846 Peer-to-Peer Streaming Tracker Protocol (PPSTP)

Authors: R. Cruz, M. Nunes, J. Xia, R. Huang, Ed., J. Taveira, D. Lingli.

Date: May 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7846

This document specifies the base Peer-to-Peer Streaming TrackerProtocol (PPSTP) version 1, an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers. The specification outlines the architecture of the protocol and its functionality; it also describes message flows, message processing instructions, message formats, formal syntax, and semantics. The PPSTP enables cooperating peers to form content- streaming overlay networks to support near real-time delivery of structured media content (audio, video, and associated timed text and metadata), such as adaptive multi-rate, layered (scalable), and multi-view (3D) videos in live, time-shifted, and on-demand modes.

RFC 7847 Logical-Interface Support for IP Hosts with Multi-Access Support

Authors: T. Melia, Ed., S. Gundavelli, Ed..

Date: May 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7847

A logical interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations.Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming, and flow mobility support. This document explains the operational details of the logical-interface construct and the specifics on how link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features.

RFC 7848 Mark and Signed Mark Objects Mapping

Authors: G. Lozano.

Date: June 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7848

Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD).
One of those special modes of operation is the Sunrise Period. TheSunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public.
This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty.

RFC 7849 An IPv6 Profile for 3GPP Mobile Devices

Authors: D. Binet, M. Boucadair, A. Vizdal, G. Chen, N. Heatley, R. Chandler, D. Michaud, D. Lopez, W. Haeffner.

Date: May 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7849

This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third GenerationPartnership Project (3GPP) Cellular Hosts document. This document defines a profile that is a superset of the connections to IPv6 cellular networks defined in "IPv6 for Third Generation PartnershipProject (3GPP) Cellular Hosts" (RFC 7066).
Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope.

RFC 7850 Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles

Authors: S. Nandakumar.

Date: April 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7850

The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following newSDP transport protocol identifiers for transporting RTP Media overTCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF','TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and'TCP/TLS/RTP/AVPF'.

RFC 7851 Peer-to-Peer (P2P) Overlay Diagnostics

Authors: H. Song, X. Jiang, R. Even, D. Bryan, Y. Sun.

Date: May 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7851

This document describes mechanisms for Peer-to-Peer (P2P) overlay diagnostics. It defines extensions to the REsource LOcation AndDiscovery (RELOAD) base protocol to collect diagnostic information and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics.

RFC 7852 Additional Data Related to an Emergency Call

Authors: R. Gellens, B. Rosen, H. Tschofenig, R. Marshall, J. Winterbottom.

Date: July 2016

Formats: txt html json

Updates: RFC 6443, RFC 6881

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7852

When an emergency call is sent to a Public Safety Answering Point(PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency.This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.
The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference.

RFC 7853 A URN Namespace for Globus

Authors: S. Martin, S. Tuecke, B. McCollam, M. Lidman.

Date: May 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7853

This document describes a URN (Uniform Resource Name) namespace to be used by Globus for naming persistent resources.

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 7855 Source Packet Routing in Networking (SPRING) Problem Statement and Requirements

Authors: S. Previdi, Ed., C. Filsfils, Ed., B. Decraene, S. Litkowski, M. Horneffer, R. Shakir.

Date: May 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7855

The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term"source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).
This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing inNetworking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document.

RFC 7856 Softwire Mesh Management Information Base (MIB)

Authors: Y. Cui, J. Dong, P. Wu, M. Xu, A. Yla-Jaaski.

Date: May 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7856

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing a softwire mesh.

RFC 7857 Updates to Network Address Translation (NAT) Behavioral Requirements

Authors: R. Penno, S. Perreault, M. Boucadair, Ed., S. Sivakumar, K. Naito.

Date: April 2016

Formats: txt html json

Updates: RFC 4787, RFC 5382, RFC 5508

Also: BCP 0127

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7857

This document clarifies and updates several requirements of RFCs4787, 5382, and 5508 based on operational and development experience.The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44).
This document updates RFCs 4787, 5382, and 5508.

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 7859 Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols

Authors: C. Dearlove.

Date: May 2016

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7859

This document extends RFC 7182, which specifies a framework for (and specific examples of) Integrity Check Values (ICVs) for packets and messages using the generalized packet/message format specified in RFC5444. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an Identity-BasedSignature (IBS), defined according to the Elliptic Curve-BasedCertificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507.

RFC 7860 HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3

Authors: J. Merkle, Ed., M. Lochter.

Date: April 2016

Formats: txt json html

Obsoletes: RFC 7630

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7860

This document specifies several authentication protocols based on theSHA-2 hash functions for the User-based Security Model (USM) forSNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIBMODULE-IDENTITY value was incorrectly specified.

RFC 7861 Remote Procedure Call (RPC) Security Version 3

Authors: A. Adamson, N. Williams.

Date: November 2016

Formats: txt json html

Updates: RFC 5403

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7861

This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides support for multi-principal authentication of client hosts and user principals to a server (constructed by generic composition), security label assertions for multi-level security and type enforcement, structured privilege assertions, and channel bindings. This document updatesRFC 5403.

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 7863 Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description

Authors: T. Haynes.

Date: November 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7863

This document provides the External Data Representation (XDR) description for NFS version 4 minor version 2.

RFC 7864 Proxy Mobile IPv6 Extensions to Support Flow Mobility

Authors: CJ. Bernardos, Ed..

Date: May 2016

Formats: txt json html

Updates: RFC 5213

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7864

Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the same PMIPv6 domain through different interfaces. This document describes extensions to the PMIPv6 protocol that are required to support network-based flow mobility over multiple physical interfaces.
This document updates RFC 5213. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management.

RFC 7865 Session Initiation Protocol (SIP) Recording Metadata

Authors: R. Ravindranath, P. Ravindran, P. Kyzivat.

Date: May 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7865

Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons.The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format.

RFC 7866 Session Recording Protocol

Authors: L. Portman, H. Lum, Ed., C. Eckel, A. Johnston, A. Hutton.

Date: May 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7866

This document specifies the use of the Session Initiation Protocol(SIP), the Session Description Protocol (SDP), and the Real-timeTransport Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The SessionRecording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session RecordingClient (SRC), which is on the path of the CS, and a Session RecordingServer (SRS) at the recording device. This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document.

RFC 7867 RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications

Authors: R. Huang.

Date: July 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7867

This document defines a new RTP Control Protocol (RTCP) ExtendedReport (XR) block that allows the reporting of loss concealment metrics for video applications of RTP.

RFC 7868 Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)

Authors: D. Savage, J. Ng, S. Moore, D. Slice, P. Paluch, R. White.

Date: May 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7868

This document describes the protocol design and architecture forEnhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing protocol based on Distance Vector technology. The specific algorithm used is called "DUAL", a Diffusing Update Algorithm as referenced in "Loop-Free Routing Using Diffusing Computations"(Garcia-Luna-Aceves 1993). The algorithm and procedures were researched, developed, and simulated by SRI International.

RFC 7869 The "vnc" URI Scheme

Authors: D. Warden, I. Iordanov.

Date: May 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7869

Virtual Network Computing (VNC) software provides remote desktop functionality. This document describes a Uniform Resource Identifier(URI) scheme enabling the launch of VNC clients from other applications. The scheme specifies parameters useful in securely connecting clients with remote hosts.

RFC 7870 Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs)

Authors: Y. Fu, S. Jiang, J. Dong, Y. Chen.

Date: June 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7870

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 managed objects for Address FamilyTransition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).

RFC 7871 Client Subnet in DNS Queries

Authors: C. Contavalli, W. van der Gaast, D. Lawrence, W. Kumari.

Date: May 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7871

This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.

RFC 7872 Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World

Authors: F. Gont, J. Linkova, T. Chown, W. Liu.

Date: June 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7872

This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet(as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.

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 7874 WebRTC Audio Codec and Processing Requirements

Authors: JM. Valin, C. Bran.

Date: May 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7874

This document outlines the audio codec and processing requirements for WebRTC endpoints.

RFC 7875 Additional WebRTC Audio Codecs for Interoperability

Authors: S. Proust, Ed..

Date: May 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7875

To ensure a baseline of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility of establishing the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser.
This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the use cases most relevant to interoperability.

RFC 7876 UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks

Authors: S. Bryant, S. Sivabalan, S. Soni.

Date: July 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7876

RFC 6374 defines a protocol for Packet Loss and Delay Measurement forMPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.

RFC 7877 Session Peering Provisioning Framework (SPPF)

Authors: K. Cartwright, V. Bhatia, S. Ali, D. Schwartz.

Date: August 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7877

This document specifies the data model and the overall structure for a framework to provision Session Establishment Data (SED) intoSession Data Registries and SIP Service Provider (SSP) data stores.The framework is called the "Session Peering Provisioning Framework"(SPPF). The provisioned data is typically used by network elements for session establishment.

RFC 7878 Session Peering Provisioning (SPP) Protocol over SOAP

Authors: K. Cartwright, V. Bhatia, J-F. Mule, A. Mayrhofer.

Date: August 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7878

The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision Session EstablishmentData (SED) into Session Data Registries and SIP Service Provider data stores. To utilize this framework, one needs a substrate protocol.Given that the Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the substrate protocol for SPPF. The benefits include leveraging prevalent expertise and a higher probability that existing provisioning systems will be able to easily migrate to using an SPPF- based protocol.

RFC 7879 DTLS-SRTP Handling in SIP Back-to-Back User Agents

Authors: R. Ravindranath, T. Reddy, G. Salgueiro, V. Pascual, P. Ravindran.

Date: May 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7879

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints. This document describes the behavior of B2BUAs when Secure Real-timeTransport (SRTP) security context is set up with the DatagramTransport Layer Security (DTLS) protocol.

RFC 7880 Seamless Bidirectional Forwarding Detection (S-BFD)

Authors: C. Pignataro, D. Ward, N. Akiya, M. Bhatia, S. Pallagatti.

Date: July 2016

Formats: txt json html

Updates: RFC 5880

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7880

This document defines Seamless Bidirectional Forwarding Detection(S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.
This document updates RFC 5880.

RFC 7881 Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS

Authors: C. Pignataro, D. Ward, N. Akiya.

Date: July 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7881

This document defines procedures for using Seamless BidirectionalForwarding Detection (S-BFD) in IPv4, IPv6, and MPLS environments.

RFC 7882 Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases

Authors: S. Aldrin, C. Pignataro, G. Mirsky, N. Kumar.

Date: July 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7882

This document describes various use cases for Seamless BidirectionalForwarding Detection (S-BFD) and provides requirements such that protocol mechanisms allow for simplified detection of forwarding failures.
These use cases support S-BFD, which is a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, accelerating the establishment of a BFD session. The benefits ofS-BFD include quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.

RFC 7883 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS

Authors: L. Ginsberg, N. Akiya, M. Chen.

Date: July 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7883

This document defines a means of advertising one or more SeamlessBidirectional Forwarding Detection (S-BFD) Discriminators using theIS-IS Router CAPABILITY TLV.

RFC 7884 OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators

Authors: C. Pignataro, M. Bhatia, S. Aldrin, T. Ranganath.

Date: July 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7884

This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional ForwardingDetection (S-BFD) Discriminator values associated with a target network identifier. This mechanism is applicable to both OSPFv2 andOSPFv3.

RFC 7885 Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV)

Authors: V. Govindan, C. Pignataro.

Date: July 2016

Formats: txt json html

Updates: RFC 5885

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7885

This document defines Seamless BFD (S-BFD) for VCCV by extending the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual CircuitConnectivity Verification (VCCV).
This document updates RFC 5885 by extending the CV Type values and the capability selection.

RFC 7886 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3)

Authors: V. Govindan, C. Pignataro.

Date: July 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7886

This document defines a new Attribute-Value Pair (AVP) that allowsL2TP Control Connection Endpoints (LCCEs) to advertise one or moreSeamless Bidirectional Forwarding Detection (S-BFD) Discriminator values using the Layer Two Tunneling Protocol version 3 (L2TPv3).

RFC 7887 Hierarchical Join/Prune Attributes

Authors: S. Venaas, J. Arango, I. Kouvelas.

Date: June 2016

Formats: txt html json

Updates: RFC 5384

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7887

This document defines a hierarchical method of encoding Join/Prune attributes that provides a more efficient encoding when the same attribute values need to be specified for multiple sources in a PIMJoin/Prune message. This document updates RFC 5384 by renaming the encoding type registry specified there.

RFC 7888 IMAP4 Non-synchronizing Literals

Authors: A. Melnikov, Ed..

Date: May 2016

Formats: txt json html

Obsoletes: RFC 2088

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7888

The Internet Message Access Protocol (RFC 3501) contains the"literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP 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 that does not require this network round trip.
This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-.LITERAL+ allows the alternate form of literals in all IMAP commands.LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.
This document obsoletes RFC 2088.

RFC 7889 The IMAP APPENDLIMIT Extension

Authors: J. SrimushnamBoovaraghamoorthy, N. Bisht.

Date: May 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7889

This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large.

RFC 7890 Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)

Authors: D. Bryan, P. Matthews, E. Shim, D. Willis, S. Dawkins.

Date: June 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7890

This document defines concepts and terminology for using the SessionInitiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message-routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a Distributed Hash Table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group, the REsource LOcation And Discovery (RELOAD) protocol, and theSIP usage document defined by the working group.

RFC 7891 Explicit Reverse Path Forwarding (RPF) Vector

Authors: J. Asghar, IJ. Wijnands, Ed., S. Krishnaswamy, A. Karan, V. Arya.

Date: June 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7891

The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the source or Rendezvous Point associated with the multicast tree.
This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, thus bypassing the unicast route lookup.

RFC 7892 IANA Allocation Procedures for the GMPLS OTN Signal Type Registry

Authors: Z. Ali, A. Bonfanti, M. Hartley, F. Zhang.

Date: May 2016

Formats: txt html json

Updates: RFC 7139

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7892

IANA defined the "OTN Signal Type" subregistry of the "GeneralizedMulti-Protocol Label Switching (GMPLS) Signaling Parameters" registry in RFC 7139. This document updates the "OTN Signal Type" subregistry to allow registration via Specification Required.

RFC 7893 Pseudowire Congestion Considerations

Authors: Y(J) Stein, D. Black, B. Briscoe.

Date: June 2016

Formats: txt html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7893

Pseudowires (PWs) have become a common mechanism for tunneling traffic and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. Thus, it is worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a bound under which such PWs consume no more network capacity than a TCP flow. For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater, and is typically much lower, than this bound.Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow. If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required.

RFC 7894 Alternative Challenge Password Attributes for Enrollment over Secure Transport

Authors: M. Pritikin, C. Wallace.

Date: June 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7894

This document defines a set of new Certificate Signing Request attributes for use with the Enrollment over Secure Transport (EST) protocol. These attributes provide disambiguation of the existing overloaded uses for the challengePassword attribute defined in "PKCS#9: Selected Object Classes and Attribute Types Version 2.0" (RFC2985). Uses include the original certificate revocation password, common authentication password uses, and EST-defined linking of transport security identity.

RFC 7895 YANG Module Library

Authors: A. Bierman, M. Bjorklund, K. Watsen.

Date: June 2016

Formats: txt json html

Obsoleted by: RFC 8525

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7895

This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information.

RFC 7896 Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)

Authors: D. Dhody.

Date: June 2016

Formats: txt html json

Updates: RFC 5440

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7896

The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit.
This document updates RFC 5440 regarding the IRO specification.

RFC 7897 Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)

Authors: D. Dhody, U. Palle, R. Casellas.

Date: June 2016

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7897

The ability to compute shortest constrained Traffic Engineering LabelSwitched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an InteriorGateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by PathComputation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains. This document also defines new subobjects to be used to encode domain identifiers.

RFC 7898 Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE)

Authors: D. Dhody, U. Palle, V. Kondreddy, R. Casellas.

Date: June 2016

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7898

The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching(GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup.
This document specifies new subobjects to include or excludeAutonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup.

RFC 7899 Multicast VPN State Damping

Authors: T. Morin, Ed., S. Litkowski, K. Patel, Z. Zhang, R. Kebler, J. Haas.

Date: June 2016

Formats: txt json html

Updates: RFC 6514

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7899

This document describes procedures to damp Multicast VPN (MVPN) routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control-plane load increase in the core routing infrastructure. The new procedures proposed were inspired by BGP unicast route damping principles that have been adapted to multicast.

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 7901 CHAIN Query Requests in DNS

Authors: P. Wouters.

Date: June 2016

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7901

This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once. This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks.

RFC 7902 Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags

Authors: E. Rosen, T. Morin.

Date: June 2016

Formats: txt html json

Updates: RFC 6514

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7902

The BGP-based control procedures for Multicast Virtual PrivateNetworks (MVPNs) make use of a BGP attribute known as the"P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the "Flags" field contains only eight bits, this document also defines a new BGP Extended Community,"Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the "P-Multicast Service Interface (PMSI)Tunnel" attribute. This document updates RFC 6514.

RFC 7903 Windows Image Media Types

Authors: S. Leonard.

Date: September 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7903

This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile,Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and they may contain both vector and raster graphics.

RFC 7904 A SIP Usage for REsource LOcation And Discovery (RELOAD)

Authors: C. Jennings, B. Lowekamp, E. Rescorla, S. Baset, H. Schulzrinne, T. Schmidt, Ed..

Date: October 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7904

This document defines a SIP Usage for REsource LOcation And Discovery(RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also definesGlobally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged.

RFC 7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)

Authors: A. Langley, W. Chang, N. Mavrogiannopoulos, J. Strombergson, S. Josefsson.

Date: June 2016

Formats: txt json html

Updates: RFC 5246, RFC 6347

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7905

This document describes the use of the ChaCha stream cipher andPoly1305 authenticator in the Transport Layer Security (TLS) andDatagram Transport Layer Security (DTLS) protocols.
This document updates RFCs 5246 and 6347.

RFC 7906 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes

Authors: P. Timmel, R. Housley, S. Turner.

Date: June 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7906

This document defines key management attributes used by the NationalSecurity Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic MessageSyntax (CMS) content types that subsequently envelope the key packages. Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used.

RFC 7908 Problem Definition and Classification of BGP Route Leaks

Authors: K. Sriram, D. Montgomery, D. McPherson, E. Osterweil, B. Dickson.

Date: June 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7908

A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking. This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention.Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community.

RFC 7909 Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures

Authors: R. Kisteleki, B. Haberman.

Date: June 2016

Formats: txt json html

Updates: RFC 2622, RFC 4012

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7909

This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications of such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on RoutingPolicy System Security) of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects.

RFC 7910 Interoperability between the Virtual Router Redundancy Protocol and PIM

Authors: W. Zhou.

Date: June 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7910

This document introduces VRRP-aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with theVirtual Router Redundancy Protocol (VRRP). It allows PIM to trackVRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled. The mechanism described in this document is based on Cisco IOS software implementation.

RFC 7911 Advertisement of Multiple Paths in BGP

Authors: D. Walton, A. Retana, E. Chen, J. Scudder.

Date: July 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7911

This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix.

RFC 7912 Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure

Authors: A. Melnikov.

Date: June 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7912

This document describes a procedure for when a Military MessageHandling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more AuthorizingUsers authorize release of the message by adding theMMHS-Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and the review signatures.

RFC 7913 P-Access-Network-Info ABNF Update

Authors: C. Holmberg.

Date: June 2016

Formats: txt html json

Updates: RFC 7315

Status: INFORMATIONAL

DOI: 10.17487/RFC 7913

This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus-Naur Form (ABNF), and by adding the following 'access-info' header field parameter values to the list of 'access-info' header field parameter values in the ABNF: 'operator-specific-GI' and'utran-sai-3gpp'. The values are defined in the ABNF but are not included in the list.

RFC 7914 The scrypt Password-Based Key Derivation Function

Authors: C. Percival, S. Josefsson.

Date: August 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7914

This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema.

RFC 7915 IP/ICMP Translation Algorithm

Authors: C. Bao, X. Li, F. Baker, T. Anderson, F. Gont.

Date: June 2016

Formats: txt json html

Obsoletes: RFC 6145

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7915

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 6145.

RFC 7916 Operational Management of Loop-Free Alternates

Authors: S. Litkowski, Ed., B. Decraene, C. Filsfils, K. Raza, M. Horneffer, P. Sarkar.

Date: July 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7916

Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IPFast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.
This proposal is also applicable to remote-LFA solutions.

RFC 7917 Advertising Node Administrative Tags in IS-IS

Authors: P. Sarkar, Ed., H. Gredler, S. Hegde, S. Litkowski, B. Decraene.

Date: July 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7917

This document describes an extension to the IS-IS routing protocol to advertise node administrative tags. This optional capability allows tagging and grouping of the nodes in an IS-IS domain. The node administrative tags can be used to express and apply locally defined network policies, thereby providing a very useful operational capability. Node administrative tags may be used by either IS-IS itself or other applications consuming information propagated via IS-IS.

RFC 7918 Transport Layer Security (TLS) False Start

Authors: A. Langley, N. Modadugu, B. Moeller.

Date: August 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7918

This document specifies an optional behavior of Transport LayerSecurity (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip.

RFC 7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

Authors: D. Gillmor.

Date: August 2016

Formats: txt json html

Updates: RFC 2246, RFC 4346, RFC 4492, RFC 5246

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7919

Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings.These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.
This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography(ECC) extensions (RFC 4492).

RFC 7920 Problem Statement for the Interface to the Routing System

Authors: A. Atlas, Ed., T. Nadeau, Ed., D. Ward.

Date: June 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7920

Traditionally, routing systems have implemented routing and signaling(e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies.Requirements have emerged to more dynamically manage and program routing systems due to the advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems.
This document proposes meeting this need via an Interface to theRouting System (I2RS).

RFC 7921 An Architecture for the Interface to the Routing System

Authors: A. Atlas, J. Halpern, S. Hares, D. Ward, T. Nadeau.

Date: June 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7921

This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS).

RFC 7922 Interface to the Routing System (I2RS) Traceability: Framework and Information Model

Authors: J. Clarke, G. Salgueiro, C. Pignataro.

Date: June 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7922

This document describes a framework for traceability in the Interface to the Routing System (I2RS) and the information model for that framework. It specifies the motivation, requirements, and use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when.It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes.

RFC 7923 Requirements for Subscription to YANG Datastores

Authors: E. Voit, A. Clemm, A. Gonzalez Prieto.

Date: June 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7923

This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., NetworkConfiguration Protocol (NETCONF) and RESTCONF). Such a service can be summarized as a "pub/sub" service for YANG datastore updates.Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees.

RFC 7924 Transport Layer Security (TLS) Cached Information Extension

Authors: S. Santesson, H. Tschofenig.

Date: July 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7924

Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).
This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.

RFC 7925 Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things

Authors: H. Tschofenig, Ed., T. Fossati.

Date: July 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7925

A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.
This document defines a Transport Layer Security (TLS) and DatagramTransport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.

RFC 7926 Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks

Authors: A. Farrel, Ed., J. Drake, N. Bitar, G. Swallow, D. Ceccarelli, X. Zhang.

Date: July 2016

Formats: txt html json

Also: BCP 0206

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7926

In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.
In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity.This subset of TE information is called TE reachability information.
This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to- end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.

RFC 7927 Information-Centric Networking (ICN) Research Challenges

Authors: D. Kutscher, Ed., S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, M. Waehlisch.

Date: July 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7927

This memo describes research challenges for Information-CentricNetworking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching.Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG).

RFC 7928 Characterization Guidelines for Active Queue Management (AQM)

Authors: N. Kuhn, Ed., P. Natarajan, Ed., N. Khademi, Ed., D. Ros.

Date: July 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7928

Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet-scheduling scheme such as fair queuing.This document describes various criteria for performing characterizations of AQM schemes that can be used in lab testing during development, prior to deployment.

RFC 7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP

Authors: P. Wouters.

Date: August 2016

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7929

OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies aDANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the"web of trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted.

RFC 7930 Larger Packets for RADIUS over TCP

Authors: S. Hartman.

Date: August 2016

Formats: txt json html

Updates: RFC 6613

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7930

The RADIUS-over-TLS experiment described in RFC 6614 has openedRADIUS to new use cases where the 4096-octet maximum size limit of aRADIUS packet proves problematic. This specification extends theRADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval.

RFC 7931 NFSv4.0 Migration: Specification Update

Authors: D. Noveck, Ed., P. Shivam, C. Lever, B. Baker.

Date: July 2016

Formats: txt json html

Updates: RFC 7530

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7931

The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0.This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC7530.

RFC 7932 Brotli Compressed Data Format

Authors: J. Alakuijala, Z. Szabadka.

Date: July 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7932

This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.

RFC 7933 Adaptive Video Streaming over Information-Centric Networking (ICN)

Authors: C. Westphal, Ed., S. Lederer, D. Posch, C. Timmerer, A. Azgin, W. Liu, C. Mueller, A. Detti, D. Corujo, J. Wang, M. Montpetit, N. Murray.

Date: August 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7933

This document considers the consequences of moving the underlying network architecture from the current Internet to an Information-Centric Networking (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms.Several important topics related to video distribution over ICN are presented. The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture ExpertsGroup (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms.

RFC 7934 Host Address Availability Recommendations

Authors: L. Colitti, V. Cerf, S. Cheshire, D. Schinazi.

Date: July 2016

Formats: txt json html

Also: BCP 0204

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7934

This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so.

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 7936 Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry

Authors: T. Hardie.

Date: July 2016

Formats: txt html json

Updates: RFC 6455

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7936

This document clarifies the instructions to IANA for the subprotocol registry set up for WebSockets in RFC 6455.

RFC 7937 Content Distribution Network Interconnection (CDNI) Logging Interface

Authors: F. Le Faucheur, Ed., G. Bertrand, Ed., I. Oprescu, Ed., R. Peterkofsky.

Date: August 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7937

This memo specifies the Logging interface between a downstreamContent Distribution Network (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework.First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files.

RFC 7938 Use of BGP for Routing in Large-Scale Data Centers

Authors: P. Lapukhov, A. Premji, J. Mitchell, Ed..

Date: August 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7938

Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry.

RFC 7939 Definition of Managed Objects for the Neighborhood Discovery Protocol

Authors: U. Herberg, R. Cole, I. Chakeres, T. Clausen.

Date: August 2016

Formats: txt json html

Obsoletes: RFC 6779

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7939

This document replaces RFC 6779; it contains revisions and extensions to the original document. It defines a portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The extensions described in this document add objects and values to support the NHDP optimization specified in RFC7466. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications aboutNHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery.

RFC 7940 Representing Label Generation Rulesets Using XML

Authors: K. Davies, A. Freytag.

Date: August 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7940

This document describes a method of representing rules for validating identifier labels and alternate representations of those labels usingExtensible Markup Language (XML). These policies, known as "LabelGeneration Rulesets" (LGRs), are used for the implementation ofInternationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants.

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 7942 Improving Awareness of Running Code: The Implementation Status Section

Authors: Y. Sheffer, A. Farrel.

Date: July 2016

Formats: txt json html

Obsoletes: RFC 6982

Also: BCP 0205

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7942

This document describes a simple process that allows authors ofInternet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

RFC 7943 A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Authors: F. Gont, W. Liu.

Date: September 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7943

This document describes a method for selecting IPv6 InterfaceIdentifiers that can be employed by Dynamic Host ConfigurationProtocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless AddressAutoconfiguration.

RFC 7944 Diameter Routing Message Priority

Authors: S. Donovan.

Date: August 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7944

When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information,Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions.

RFC 7945 Information-Centric Networking: Evaluation and Security Considerations

Authors: K. Pentikousis, Ed., B. Ohlman, E. Davies, S. Spirou, G. Boggia.

Date: September 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7945

This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.

RFC 7946 The GeoJSON Format

Authors: H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub.

Date: August 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7946

GeoJSON is a geospatial data interchange format based on JavaScriptObject Notation (JSON). It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents.GeoJSON uses a geographic coordinate reference system, World GeodeticSystem 1984, and units of decimal degrees.

RFC 7947 Internet Exchange BGP Route Server

Authors: E. Jasinska, N. Hilliard, R. Raszuk, N. Bakker.

Date: September 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7947

This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such asIXPs, to facilitate simplified interconnection among multipleInternet routers.

RFC 7948 Internet Exchange BGP Route Server Operations

Authors: N. Hilliard, E. Jasinska, R. Raszuk, N. Bakker.

Date: September 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7948

The popularity of Internet Exchange Points (IXPs) brings new challenges to interconnecting networks. While bilateral External BGP(EBGP) sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants.
Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information.
This document describes operational considerations for multilateral interconnections at IXPs.

RFC 7949 OSPFv3 over IPv4 for IPv6 Transition

Authors: I. Chen, A. Lindem, R. Atkinson.

Date: August 2016

Formats: txt html json

Updates: RFC 5838

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7949

This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 AddressFamily extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4.

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 7951 JSON Encoding of Data Modeled with YANG

Authors: L. Lhotka.

Date: August 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7951

This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG asJavaScript Object Notation (JSON) text.

RFC 7952 Defining and Using Metadata with YANG

Authors: L. Lhotka.

Date: August 2016

Formats: txt json html

Updates: RFC 6110

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7952

This document defines a YANG extension that allows for defining metadata annotations in YANG modules. The document also specifiesXML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes.

RFC 7953 Calendar Availability

Authors: C. Daboo, M. Douglass.

Date: August 2016

Formats: txt json html

Updates: RFC 4791, RFC 5545, RFC 6638

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7953

This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendarTransport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed.
This document also defines extensions to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the associated scheduling protocol (RFC 6638) to specify how this new calendar component can be used when evaluating free-busy time.

RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block

Authors: L. Iannone, D. Lewis, D. Meyer, V. Fuller.

Date: September 2016

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 7954

This document directs IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space.

RFC 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block

Authors: L. Iannone, R. Jorgensen, D. Conrad, G. Huston.

Date: September 2016

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 7955

This document proposes a framework for the management of the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) address block. The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations.

RFC 7956 Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway

Authors: W. Hao, Y. Li, A. Qu, M. Durrani, P. Sivamurugan.

Date: September 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7956

The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter- subnet traffic forwarding but has the following issues:
1. Sub-optimum forwarding paths for inter-subnet traffic.
2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per DataLabel used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus.
3. A traffic bottleneck at the gateway.
This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues.

RFC 7957 DISPATCH-Style Working Groups and the SIP Change Process

Authors: B. Campbell, Ed., A. Cooper, B. Leiba.

Date: August 2016

Formats: txt json html

Updates: RFC 5727

Also: BCP 0067

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 7957

RFC 5727 defined several processes for the former Real-timeApplications and Infrastructure (RAI) area. These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups. This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes. It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups.

RFC 7958 DNSSEC Trust Anchor Publication for the Root Zone

Authors: J. Abley, J. Schlyter, G. Bailey, P. Hoffman.

Date: August 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7958

The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC).
In order to obtain secure answers from the root zone of the DNS usingDNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors.

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 7960 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows

Authors: F. Martin, Ed., E. Lear, Ed., T. Draegen, Ed., E. Zwicky, Ed., K. Andersen, Ed..

Date: September 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7960

Domain-based Message Authentication, Reporting, and Conformance(DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients.Collectively, these email flows are referred to as "indirect email flows". This document describes these interoperability issues and presents possible methods for addressing them.

RFC 7961 Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV

Authors: D. Eastlake 3rd, L. Yizhou.

Date: August 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7961

This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by aTRILL switch of sets of addresses. Each set of addresses reports all of the addresses that designate the same interface (port) and also reports the TRILL switch by which that interface is reachable. For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch. Such information could be used in some cases to synthesize responses to, or bypass the need for, the Address Resolution Protocol (ARP), the IPv6 NeighborDiscovery (ND) protocol, or the flooding of unknown MAC addresses.

RFC 7962 Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures

Authors: J. Saldana, Ed., A. Arcia-Moret, B. Braem, E. Pietrosemoli, A. Sathiaseelan, M. Zennaro.

Date: August 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7962

This document presents a taxonomy of a set of "Alternative NetworkDeployments" that emerged in the last decade with the aim of bringingInternet connectivity to people or providing a local communication infrastructure to serve various complementary needs and objectives.They employ architectures and topologies different from those of mainstream networks and rely on alternative governance and business models.
The document also surveys the technologies deployed in these networks, and their differing architectural characteristics, including a set of definitions and shared properties.
The classification considers models such as Community Networks,Wireless Internet Service Providers (WISPs), networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, networks that provide connectivity by sharing wireless resources of the users, and rural utility cooperatives.

RFC 7963 RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs)

Authors: Z. Ali, A. Bonfanti, M. Hartley, F. Zhang.

Date: August 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7963

RFCs 4328 and 7139 provide signaling extensions in ResourceReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features. However, these specifications do not cover the additional Optical channel Data Unit(ODU) containers defined in G.Sup43 (ODU1e, ODU3e1, and ODU3e2).This document defines new Signal Types for these additional containers.

RFC 7964 Solutions for BGP Persistent Route Oscillation

Authors: D. Walton, A. Retana, E. Chen, J. Scudder.

Date: September 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7964

Routing information reduction by BGP Route Reflection orConfederation can result in persistent internal BGP route oscillations with certain routing setups and network topologies.This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network.

RFC 7965 LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels

Authors: M. Chen, W. Cao, A. Takacs, P. Pan.

Date: August 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7965

Many transport services require that user traffic, in the form ofPseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes. This document defines an optional extension to theLabel Distribution Protocol (LDP) that enables the binding betweenPWs and the underlying Traffic Engineering (TE) tunnels. The extension applies to both single-segment and multi-segment PWs.

RFC 7966 Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements

Authors: H. Tschofenig, J. Korhonen, Ed., G. Zorn, K. Pillay.

Date: September 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7966

This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs).

RFC 7967 Constrained Application Protocol (CoAP) Option for No Server Response

Authors: A. Bhattacharyya, S. Bandyopadhyay, A. Pal, T. Bose.

Date: August 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7967

There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.
This specification introduces a CoAP option called 'No-Response'.Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request.This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of theNo-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.

RFC 7968 Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data

Authors: Y. Li, D. Eastlake 3rd, W. Hao, H. Chen, S. Chatterjee.

Date: August 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7968

TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address. If any VLAN,FGL, or multicast group can be sent on any tree, for typical fast- path hardware, the amount of pruning information is multiplied by the number of trees, but there is limited hardware capacity for such pruning information.
This document specifies an optional facility to restrict the TRILLData packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups, thus reducing the total amount of pruning information so that it can more easily be accommodated by fast-path hardware.

RFC 7969 Customizing DHCP Configuration on the Basis of Network Topology

Authors: T. Lemon, T. Mrugalski.

Date: October 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7969

DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications.One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation.

RFC 7970 The Incident Object Description Exchange Format Version 2

Authors: R. Danyliw.

Date: November 2016

Formats: txt html json

Obsoletes: RFC 5070, RFC 6685

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7970

The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema. This new information and data model obsoletesRFCs 5070 and 6685.

RFC 7971 Application-Layer Traffic Optimization (ALTO) Deployment Considerations

Authors: M. Stiemerling, S. Kiesel, M. Scharf, H. Seidel, S. Previdi.

Date: October 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7971

Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource.This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing andContent Delivery Networks (CDNs) and presents corresponding examples.The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information.

RFC 7972 Entertainment Identifier Registry (EIDR) URN Namespace Definition

Authors: P. Lemieux.

Date: September 2016

Formats: txt json html

Obsoletes: RFC 7302

Status: INFORMATIONAL

DOI: 10.17487/RFC 7972

Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name(URN) Namespace Identifier (NID) for EIDR Identifiers.
This document obsoletes RFC 7302.

RFC 7973 Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation

Authors: R. Droms, P. Duffy.

Date: November 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7973

When carried over Layer 2 technologies such as Ethernet, IPv6 datagrams using Low-Power Wireless Personal Area Network (LoWPAN) encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram. The IETF officially requested the assignment of an Ethertype for that purpose and this document reports that assignment.

RFC 7974 An Experimental TCP Option for Host Identification

Authors: B. Williams, M. Boucadair, D. Wing.

Date: October 2016

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 7974

Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed.This memo describes the design, deployment, and privacy considerations for one such solution in operational use on theInternet today that uses a TCP option to transmit a host identifier.

RFC 7975 Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection

Authors: B. Niven-Jenkins, Ed., R. van Brandenburg, Ed..

Date: October 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7975

The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream ContentDelivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface.

RFC 7976 Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses

Authors: C. Holmberg, N. Biondic, G. Salgueiro.

Date: September 2016

Formats: txt json html

Updates: RFC 7315

Status: INFORMATIONAL

DOI: 10.17487/RFC 7976

The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315.This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses.
This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315.

RFC 7977 The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)

Authors: P. Dunkley, G. Llewellyn, V. Pascual, G. Salgueiro, R. Ravindranath.

Date: September 2016

Formats: txt json html

Updates: RFC 4975, RFC 4976

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7977

The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser). This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol(MSRP) clients and relays to enable usage of MSRP in new scenarios.This document normatively updates RFCs 4975 and 4976.

RFC 7978 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension

Authors: D. Eastlake 3rd, M. Umair, Y. Li.

Date: September 2016

Formats: txt html json

Updates: RFC 7178

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7978

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages betweenTRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link.This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages. This document updates RFC 7178.

RFC 7979 Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries

Authors: E. Lear, Ed., R. Housley, Ed..

Date: August 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7979

The U.S. National Telecommunications and Information Administration(NTIA) solicited a request from the Internet Corporation for AssignedNames and Numbers (ICANN) to propose how the NTIA should end its oversight of the Internet Assigned Numbers Authority (IANA) functions. After broad consultations, ICANN in turn created the IANAStewardship Transition Coordination Group. That group solicited proposals for the three major IANA functions: names, numbers, and protocol parameters. This document contains the IETF response to that solicitation for protocol parameters. It was included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities. A reference to that response may be found in the introduction, and additional correspondence is included in theAppendix.

RFC 7980 A Framework for Defining Network Complexity

Authors: M. Behringer, A. Retana, R. White, G. Huston.

Date: October 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7980

Complexity is a widely used parameter in network design, yet there is no generally accepted definition of the term. Complexity metrics exist in a wide range of research papers, but most of these address only a particular aspect of a network, for example, the complexity of a graph or software. While it may be impossible to define a metric for overall network complexity, there is a desire to better understand the complexity of a network as a whole, as deployed today to provide Internet services. This document provides a framework to guide research on the topic of network complexity as well as some practical examples for trade-offs in networking.
This document summarizes the work of the IRTF's Network ComplexityResearch Group (NCRG) at the time of its closure. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work.

RFC 7981 IS-IS Extensions for Advertising Router Information

Authors: L. Ginsberg, S. Previdi, M. Chen.

Date: October 2016

Formats: txt html json

Obsoletes: RFC 4971

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7981

This document defines a new optional Intermediate System toIntermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. This document obsoletesRFC 4971.

RFC 7982 Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)

Authors: P. Martinsen, T. Reddy, D. Wing, V. Singh.

Date: September 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7982

A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience.
This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session TraversalUtilities for NAT (STUN) messages.

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 7984 Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network

Authors: O. Johansson, G. Salgueiro, V. Gurbani, D. Worley, Ed..

Date: September 2016

Formats: txt html json

Updates: RFC 3263

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7984

RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "HappyEyeballs" principles to SIP.

RFC 7985 Security Threats to Simplified Multicast Forwarding (SMF)

Authors: J. Yi, T. Clausen, U. Herberg.

Date: November 2016

Formats: txt html json

Updates: RFC 7186

Status: INFORMATIONAL

DOI: 10.17487/RFC 7985

This document analyzes security threats to Simplified MulticastForwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described.
In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network(MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130).

RFC 7986 New Properties for iCalendar

Authors: C. Daboo.

Date: October 2016

Formats: txt json html

Updates: RFC 5545

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7986

This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object.

RFC 7987 IS-IS Minimum Remaining Lifetime

Authors: L. Ginsberg, P. Wells, B. Decraene, T. Przygienda, H. Gredler.

Date: October 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7987

Corruption of the Remaining Lifetime field in a Link State ProtocolData Unit (LSP) can go undetected. In certain scenarios, this may cause or exacerbate flooding storms. It is also a possible denial- of-service attack vector. This document defines a backwards- compatible solution to this problem.

RFC 7988 Ingress Replication Tunnels in Multicast VPN

Authors: E. Rosen, Ed., K. Subramanian, Z. Zhang.

Date: October 2016

Formats: txt html json

Updates: RFC 6513, RFC 6514

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7988

RFCs 6513, 6514, and other RFCs describe procedures by which aService Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an"Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels.

RFC 7989 End-to-End Session Identification in IP-Based Multimedia Communication Networks

Authors: P. Jones, G. Salgueiro, C. Pearce, P. Giralt.

Date: October 2016

Formats: txt html json

Obsoletes: RFC 7329

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 7989

This document describes an end-to-end session identifier for use inIP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the SessionInitiation Protocol (SIP).
This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document.
This document obsoletes RFC 7329.

RFC 7990 RFC Format Framework

Authors: H. Flanagan.

Date: December 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7990

In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version3 vocabulary; different publication formats will be rendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan.

RFC 7991 The "xml2rfc" Version 3 Vocabulary

Authors: P. Hoffman.

Date: December 2016

Formats: txt html json

Obsoletes: RFC 7749

Status: INFORMATIONAL

DOI: 10.17487/RFC 7991

This document defines the "xml2rfc" version 3 vocabulary: anXML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described inRFC 7749.

RFC 7992 HTML Format for RFCs

Authors: J. Hildebrand, Ed., P. Hoffman.

Date: December 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7992

In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats. This document defines the HTML format that will be rendered for an RFC or Internet-Draft.

RFC 7993 Cascading Style Sheets (CSS) Requirements for RFCs

Authors: H. Flanagan.

Date: December 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7993

The HTML format for RFCs assigns style guidance to a Cascading StyleSheet (CSS) specifically defined for the RFC Series. The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model. This document describes the requirements for the default CSS used by the RFC Editor. The class names are based on the classes defined in "HTML for RFCs" (RFC 7992).

RFC 7994 Requirements for Plain-Text RFCs

Authors: H. Flanagan.

Date: December 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7994

In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format forRFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition.

RFC 7995 PDF Format for RFCs

Authors: T. Hansen, Ed., L. Masinter, M. Hardy.

Date: December 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7995

This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF.

RFC 7996 SVG Drawings for RFCs: SVG 1.2 RFC

Authors: N. Brownlee.

Date: December 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 7996

This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams.

RFC 7997 The Use of Non-ASCII Characters in RFCs

Authors: H. Flanagan, Ed..

Date: December 2016

Formats: txt json html pdf

Updates: RFC 7322

Status: INFORMATIONAL

DOI: 10.17487/RFC 7997

In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.
This document updates RFC 7322. Please view this document in PDF form to see the full text.

RFC 7998 "xml2rfc" Version 3 Preparation Tool Description

Authors: P. Hoffman, J. Hildebrand.

Date: December 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7998

This document describes some aspects of the "prep tool" that is expected to be created when the new xml2rfc version 3 specification is deployed.

RFC 7999 BLACKHOLE Community

Authors: T. King, C. Dietzel, J. Snijders, G. Doering, G. Hankins.

Date: October 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 7999

This document describes the use of a well-known Border GatewayProtocol (BGP) community for destination-based blackholing in IP networks. This well-known advisory transitive BGP community named"BLACKHOLE" allows an origin Autonomous System (AS) to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix.

RFC 8000 Requirements for NFSv4 Multi-Domain Namespace Deployment

Authors: A. Adamson, N. Williams.

Date: November 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8000

This document presents requirements for the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain- capable file system and support RPCSEC_GSS for user authentication.In most instances, the server must also support identity-mapping services.

RFC 8001 RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information

Authors: F. Zhang, Ed., O. Gonzalez de Dios, Ed., C. Margaria, M. Hartley, Z. Ali.

Date: January 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8001

This document provides extensions for Resource Reservation Protocol -Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP).

RFC 8002 Host Identity Protocol Certificates

Authors: T. Heer, S. Varjonen.

Date: October 2016

Formats: txt json html

Obsoletes: RFC 6253

Updates: RFC 7401

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8002

The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in HostIdentity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags (HITs) in X.509 version 3 (v3).
The concrete use cases of certificates, including how certificates are obtained and requested and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter.
This document updates RFC 7401 and obsoletes RFC 6253.

RFC 8003 Host Identity Protocol (HIP) Registration Extension

Authors: J. Laganier, L. Eggert.

Date: October 2016

Formats: txt json html

Obsoletes: RFC 5203

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8003

This document specifies a registration mechanism for the HostIdentity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC 5203.

RFC 8004 Host Identity Protocol (HIP) Rendezvous Extension

Authors: J. Laganier, L. Eggert.

Date: October 2016

Formats: txt html json

Obsoletes: RFC 5204

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8004

This document defines a rendezvous extension for the Host IdentityProtocol (HIP). The rendezvous extension extends HIP and the HIPRegistration Extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile. This document obsoletes RFC 5204.

RFC 8005 Host Identity Protocol (HIP) Domain Name System (DNS) Extension

Authors: J. Laganier.

Date: October 2016

Formats: txt html json

Obsoletes: RFC 5205

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8005

This document specifies a resource record (RR) for the Domain NameSystem (DNS) and how to use it with the Host Identity Protocol (HIP).This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its HostIdentity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs). This document obsoletes RFC 5205.

RFC 8006 Content Delivery Network Interconnection (CDNI) Metadata

Authors: B. Niven-Jenkins, R. Murray, M. Caulfield, K. Ma.

Date: December 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8006

The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNIMetadata and the protocol for exchanging that metadata.

RFC 8007 Content Delivery Network Interconnection (CDNI) Control Interface / Triggers

Authors: R. Murray, B. Niven-Jenkins.

Date: December 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8007

This document describes the part of the Content Delivery NetworkInterconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN.

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 8009 AES Encryption with HMAC-SHA2 for Kerberos 5

Authors: M. Jenkins, M. Peck, K. Burgin.

Date: October 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8009

This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode(CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity.

RFC 8010 Internet Printing Protocol/1.1: Encoding and Transport

Authors: M. Sweet, I. McDonald.

Date: January 2017

Formats: txt html json

Obsoletes: RFC 2910, RFC 3382

Also: STD 0092

Status: INTERNET STANDARD

DOI: 10.17487/RFC 8010

The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called"application/ipp". It also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP and/orHTTPS. The IPP data model and operation semantics are described in"Internet Printing Protocol/1.1: Model and Semantics" (RFC 8011).
This document obsoletes RFCs 2910 and 3382.

RFC 8011 Internet Printing Protocol/1.1: Model and Semantics

Authors: M. Sweet, I. McDonald.

Date: January 2017

Formats: txt html json

Obsoletes: RFC 2911, RFC 3381, RFC 3382

Also: STD 0092

Status: INTERNET STANDARD

DOI: 10.17487/RFC 8011

The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, attributes, and operations that is independent of encoding and transport. The model consists of several objects, including Printers and Jobs. Jobs optionally support multiple Documents.
IPP semantics allow End Users and Operators to query Printer capabilities; submit Print Jobs; inquire about the status of PrintJobs and Printers; and cancel, hold, and release Print Jobs. IPP semantics also allow Operators to pause and resume Jobs and Printers.
Security, internationalization, and directory issues are also addressed by the model and semantics. The IPP message encoding and transport are described in "Internet Printing Protocol/1.1: Encoding and Transport" (RFC 8010).
This document obsoletes RFCs 2911, 3381, and 3382.

RFC 8012 Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs)

Authors: N. Akiya, G. Swallow, C. Pignataro, A. Malis, S. Aldrin.

Date: November 2016

Formats: txt json html

Updates: RFC 6790

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8012

Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) ping and traceroute are methods used to test Equal-Cost Multipath (ECMP) paths. Ping is known as a connectivity-verification method and traceroute is known as a fault-isolation method, as described in RFC4379. When an LSP is signaled using the Entropy Label (EL) described in RFC 6790, the ability for LSP ping and traceroute operations to discover and exercise ECMP paths is lost for scenarios where LabelSwitching Routers (LSRs) apply different load-balancing techniques.One such scenario is when some LSRs apply EL-based load balancing while other LSRs apply load balancing that is not EL based (e.g.,IP). Another scenario is when an EL-based LSP is stitched with another LSP that can be EL based or not EL based.
This document extends the MPLS LSP ping and traceroute multipath mechanisms in RFC 6424 to allow the ability of exercising LSPs that make use of the EL. This document updates RFC 6790.

RFC 8013 Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)

Authors: D. Joachimpillai, J. Hadi Salim.

Date: February 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8013

This document describes how to extend the Forwarding and ControlElement Separation (ForCES) Logical Functional Block (LFB) topology across Forwarding Elements (FEs) by defining the inter-FE LFB class.The inter-FE LFB class provides the ability to pass data and metadata across FEs without needing any changes to the ForCES specification.The document focuses on Ethernet transport.

RFC 8014 An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)

Authors: D. Black, J. Hudson, L. Kreeger, M. Lasserre, T. Narten.

Date: December 2016

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8014

This document presents a high-level overview architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks. The architecture is given at a high level, showing the major components of an overall system. An important goal is to divide the space into individual smaller components that can be implemented independently with clear inter-component interfaces and interactions. It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components. That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components.

RFC 8015 RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics

Authors: V. Singh, C. Perkins, A. Clark, R. Huang.

Date: November 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8015

This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of burst/gap discard metrics independently of the burst/gap loss metrics for use in a range of RTP applications.

RFC 8016 Mobility with Traversal Using Relays around NAT (TURN)

Authors: T. Reddy, D. Wing, P. Patil, P. Martinsen.

Date: November 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8016

It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so that only the local network elements are aware of the changed IP address and the remote peer is unaware of the changed IP address.
This document provides such an IP address mobility solution usingTraversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when theIP address of the client changes.

RFC 8017 PKCS #1: RSA Cryptography Specifications Version 2.2

Authors: K. Moriarty, Ed., B. Kaliski, J. Jonsson, A. Rusch.

Date: November 2016

Formats: txt json html

Obsoletes: RFC 3447

Status: INFORMATIONAL

DOI: 10.17487/RFC 8017

This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.
This document represents a republication of PKCS #1 v2.2 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
This document also obsoletes RFC 3447.

RFC 8018 PKCS #5: Password-Based Cryptography Specification Version 2.1

Authors: K. Moriarty, Ed., B. Kaliski, A. Rusch.

Date: January 2017

Formats: txt html json

Obsoletes: RFC 2898

Status: INFORMATIONAL

DOI: 10.17487/RFC 8018

This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques.
This document represents a republication of PKCS #5 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
This document also obsoletes RFC 2898.

RFC 8019 Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks

Authors: Y. Nir, V. Smyslov.

Date: November 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8019

This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2)Responders, to allow them to resist Denial-of-Service and DistributedDenial-of-Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that helps accomplish this task.

RFC 8020 NXDOMAIN: There Really Is Nothing Underneath

Authors: S. Bortzmeyer, S. Huque.

Date: November 2016

Formats: txt html json

Updates: RFC 1034, RFC 2308

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8020

This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them.

RFC 8021 Generation of IPv6 Atomic Fragments Considered Harmful

Authors: F. Gont, W. Liu, T. Anderson.

Date: January 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8021

This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments. It concludes that the aforementioned functionality is undesirable and thus documents the motivation for removing this functionality from an upcoming revision of the core IPv6 protocol specification (RFC 2460).

RFC 8022 A YANG Data Model for Routing Management

Authors: L. Lhotka, A. Lindem.

Date: November 2016

Formats: txt json html

Obsoleted by: RFC 8349

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8022

This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes,Routing Information Bases (RIBs), and control-plane protocols.

RFC 8023 Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions

Authors: M. Thomas, A. Mankin, L. Zhang.

Date: November 2016

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8023

This document provides context and a report on the workshop on "RootCauses and Mitigation of Name Collisions", which took place inLondon, United Kingdom, from March 8 to 10, 2014. The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions. This report provides a small amount of background and context; then, it provides a summary of the workshop's discussions.

RFC 8024 Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS

Authors: Y. Jiang, Ed., Y. Luo, E. Mallette, Ed., Y. Shen, W. Cheng.

Date: November 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8024

Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks including the network access nodes. Separately, network access nodes such as Passive Optical Network (PON) OpticalLine Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multihoming support is needed on theMPLS-enabled PON OLT to provide resiliency for provided services.This document describes the Multi-Chassis PON (MC-PON) protection architecture in MPLS and also specifies the Inter-ChassisCommunication Protocol (ICCP) extension to support it.

RFC 8025 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch

Authors: P. Thubert, Ed., R. Cragie.

Date: November 2016

Formats: txt html json

Updates: RFC 4944

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8025

This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network(6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch.

RFC 8026 Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism

Authors: M. Boucadair, I. Farrer.

Date: November 2016

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8026

In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of CustomerPremises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism.

RFC 8027 DNSSEC Roadblock Avoidance

Authors: W. Hardaker, O. Gudmundsson, S. Krishnaswamy.

Date: November 2016

Formats: txt json html

Also: BCP 0207

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8027

This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face.

RFC 8028 First-Hop Router Selection by Hosts in a Multi-Prefix Network

Authors: F. Baker, B. Carpenter.

Date: November 2016

Formats: txt html json

Updates: RFC 4861

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8028

This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen.Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their RouterAdvertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC4861.

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 8030 Generic Event Delivery Using HTTP Push

Authors: M. Thomson, E. Damaggio, B. Raymor, Ed..

Date: December 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8030

This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push.

RFC 8031 Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement

Authors: Y. Nir, S. Josefsson.

Date: December 2016

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8031

This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version2 (IKEv2).

RFC 8032 Edwards-Curve Digital Signature Algorithm (EdDSA)

Authors: S. Josefsson, I. Liusvaara.

Date: January 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8032

This document describes elliptic curve signature scheme Edwards-curveDigital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.

RFC 8033 Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem

Authors: R. Pan, P. Natarajan, F. Baker, G. White.

Date: February 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8033

Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. As more and more interactive applications (e.g., voice over IP, real-time video streaming, and financial transactions) run in the Internet, high latency and latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users.
This document presents a lightweight active queue management design called "PIE" (Proportional Integral controller Enhanced) that can effectively control the average queuing latency to a target value.Simulation results, theoretical analysis, and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software.

RFC 8034 Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems

Authors: G. White, R. Pan.

Date: February 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8034

Cable modems based on Data-Over-Cable Service InterfaceSpecifications (DOCSIS) provide broadband Internet access to over one hundred million users worldwide. In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet. As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience. The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management(AQM) algorithm that is intended to alleviate the impact that buffering has on latency-sensitive traffic, while preserving bulk throughput performance. In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements. This document describes the requirements on AQM that apply to DOCSIS equipment, including a description of the"DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems.

RFC 8035 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing

Authors: C. Holmberg.

Date: November 2016

Formats: txt html json

Updates: RFC 5761

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8035

This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTP Control Protocol (RTCP) multiplexing. It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in a Session Description Protocol (SDP) answer if the associated SDP offer contained the attribute.

RFC 8036 Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks

Authors: N. Cam-Winget, Ed., J. Hui, D. Popa.

Date: January 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8036

This document discusses the applicability of the Routing Protocol forLow-Power and Lossy Networks (RPL) in Advanced MeteringInfrastructure (AMI) networks.

RFC 8037 CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)

Authors: I. Liusvaara.

Date: January 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8037

This document defines how to use the Diffie-Hellman algorithms"X25519" and "X448" as well as the signature algorithms "Ed25519" and"Ed448" from the IRTF CFRG elliptic curves work in JSON ObjectSigning and Encryption (JOSE).

RFC 8038 Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol

Authors: P. Aitken, Ed., B. Claise, S. B S, C. McDowall, J. Schoenwaelder.

Date: May 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8038

This document specifies a way to complement IP Flow InformationExport (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified.
Two IPFIX Options Templates, as well as a method for creating IPFIXOptions Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein.

RFC 8039 Multipath Time Synchronization

Authors: A. Shpiner, R. Tse, C. Schelp, T. Mizrahi.

Date: December 2016

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8039

Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time- sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols. The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance. The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality.

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 8041 Use Cases and Operational Experience with Multipath TCP

Authors: O. Bonaventure, C. Paasch, G. Detal.

Date: January 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8041

This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements.

RFC 8042 OSPF Two-Part Metric

Authors: Z. Zhang, L. Wang, A. Lindem.

Date: December 2016

Formats: txt html json

Updates: RFC 2328

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8042

This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router. For such networks, the router-to-router metric forOSPF route computation is the sum of the two parts. This document updates RFC 2328.

RFC 8043 Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space

Authors: B. Sarikaya, M. Boucadair.

Date: January 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8043

This document presents the source-address-dependent routing (SADR) problem space from the host's perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next-hop resolution are needed in view of source-address-dependent routing.
The document is scoped on identifying a set of scenarios for source-address-dependent routing from the host's perspective and analyzing a set of solutions to mitigate encountered issues. The document does not make any solution recommendations.

RFC 8044 Data Types in RADIUS

Authors: A. DeKok.

Date: January 2017

Formats: txt json html

Updates: RFC 2865, RFC 3162, RFC 4072, RFC 6158, RFC 6572, RFC 7268

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8044

RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include aData Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072,6158, 6572, and 7268.

RFC 8045 RADIUS Extensions for IP Port Configuration and Reporting

Authors: D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar.

Date: January 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8045

This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-GradeNAT, IPv4/IPv6 translators, Provider WLAN gateway, etc. This document defines a mapping between some RADIUS attributes and IP FlowInformation Export (IPFIX) Information Element identifiers.

RFC 8046 Host Mobility with the Host Identity Protocol

Authors: T. Henderson, Ed., C. Vogt, J. Arkko.

Date: February 2017

Formats: txt html json

Obsoletes: RFC 5206

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8046

This document defines a mobility extension to the Host IdentityProtocol (HIP). Specifically, this document defines a "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts.The same LOCATOR_SET parameter can also be used to support end-host multihoming (as specified in RFC 8047). This document obsoletes RFC5206.

RFC 8047 Host Multihoming with the Host Identity Protocol

Authors: T. Henderson, Ed., C. Vogt, J. Arkko.

Date: February 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8047

This document defines host multihoming extensions to the HostIdentity Protocol (HIP), by leveraging protocol components defined for host mobility.

RFC 8048 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence

Authors: P. Saint-Andre.

Date: December 2016

Formats: txt json html

Obsoletes: RFC 7248

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8048

This document defines a bidirectional protocol mapping for the exchange of presence information between the Session InitiationProtocol (SIP) and the Extensible Messaging and Presence Protocol(XMPP). This document obsoletes RFC 7248.

RFC 8049 YANG Data Model for L3VPN Service Delivery

Authors: S. Litkowski, L. Tomotaki, K. Ogaki.

Date: February 2017

Formats: txt json html

Obsoleted by: RFC 8299

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8049

This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.

RFC 8050 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions

Authors: C. Petrie, T. King.

Date: May 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8050

This document extends the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by supporting the advertisement of multiple paths in BGP extensions.

RFC 8051 Applicability of a Stateful Path Computation Element (PCE)

Authors: X. Zhang, Ed., I. Minei, Ed..

Date: January 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8051

A stateful Path Computation Element (PCE) maintains information aboutLabel Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE CommunicationProtocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.

RFC 8052 Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services

Authors: B. Weis, M. Seewald, H. Falk.

Date: June 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8052

The IEC 61850 power utility automation family of standards describes methods using Ethernet and IP for distributing control and data frames within and between substations. The IEC 61850-90-5 and IEC62351-9 standards specify the use of the Group Domain ofInterpretation (GDOI) protocol (RFC 6407) to distribute security transforms for some IEC 61850 security protocols. This memo definesGDOI payloads to support those security protocols.

RFC 8053 HTTP Authentication Extensions for Interactive Clients

Authors: Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku.

Date: January 2017

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8053

This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps betweenWeb application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication.

RFC 8054 Network News Transfer Protocol (NNTP) Extension for Compression

Authors: K. Murchison, J. Elie.

Date: January 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8054

This document defines an extension to the Network News TransportProtocol (NNTP) that allows a connection to be effectively and efficiently compressed between an NNTP client and server.

RFC 8055 Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm

Authors: C. Holmberg, Y. Jiang.

Date: January 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8055

This specification defines a new Session Initiation Protocol (SIP)Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network.

RFC 8056 Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping

Authors: J. Gould.

Date: January 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8056

This document describes the mapping of the Extensible ProvisioningProtocol (EPP) statuses with the statuses registered for use in theRegistration Data Access Protocol (RDAP). This document identifies gaps in the mapping, and registers RDAP statuses to fill those gaps to ensure that all of the EPP statuses specified in RFCs are supported in RDAP.

RFC 8057 Uniform Resource Name (URN) Namespaces for Broadband Forum

Authors: B. Stark, D. Sinicrope, W. Lupton.

Date: January 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8057

This document describes the Namespace Identifiers (NIDs) "bbf","broadband-forum-org", and "dslforum-org" for Uniform Resource Names(URNs) used to identify resources published by Broadband Forum (BBF).BBF specifies and manages resources that utilize these three URN identification models. Management activities for these and other resource types are handled by BBF.

RFC 8058 Signaling One-Click Functionality for List Email Headers

Authors: J. Levine, T. Herkula.

Date: January 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8058

This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.

RFC 8059 PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments

Authors: J. Arango, S. Venaas, I. Kouvelas, D. Farinacci.

Date: January 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8059

This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol(LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey theRLOC (Routing Locator) address of the receiver ETR (Egress TunnelRouter) to the control plane of the root ITR (Ingress Tunnel Router).

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 8061 Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality

Authors: D. Farinacci, B. Weis.

Date: February 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8061

This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks.

RFC 8062 Anonymity Support for Kerberos

Authors: L. Zhu, P. Leach, S. Hartman, S. Emery, Ed..

Date: February 2017

Formats: txt html json

Obsoletes: RFC 6112

Updates: RFC 4120, RFC 4121, RFC 4556

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8062

This document defines extensions to the Kerberos protocol to allow aKerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow aKerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletesRFC 6112 and reclassifies that document as Historic. RFC 6112 contained errors, and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations.

RFC 8063 Key Relay Mapping for the Extensible Provisioning Protocol

Authors: H.W. Ribbers, M.W. Groeneweg, R. Gieben, A.L.J. Verschuren.

Date: February 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8063

This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC 5730.
This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact.

RFC 8064 Recommendation on Stable IPv6 Interface Identifiers

Authors: F. Gont, A. Cooper, D. Thaler, W. Liu.

Date: February 2017

Formats: txt json html

Updates: RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, RFC 5121

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8064

This document changes the recommended default Interface Identifier(IID) generation scheme for cases where Stateless AddressAutoconfiguration (SLAAC) is used to generate a stable IPv6 address.It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.

RFC 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms

Authors: D. Thaler.

Date: February 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8065

This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links.

RFC 8066 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines

Authors: S. Chakrabarti, G. Montenegro, R. Droms, J. Woodyatt.

Date: February 2017

Formats: txt html json

Updates: RFC 4944, RFC 6282

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8066

RFC 4944 defines the ESC dispatch type to allow additional dispatch octets in the 6LoWPAN header. The value of the ESC dispatch type was updated by RFC 6282; however, its usage was not defined in either RFC6282 or RFC 4944. This document updates RFC 4944 and RFC 6282 by defining the ESC extension octet code points and listing registration entries for known use cases at the time of writing of this document.

RFC 8067 Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level

Authors: B. Leiba.

Date: January 2017

Formats: txt html json

Updates: RFC 3967

Also: BCP 0097

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8067

RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"), which involves calling out the downref explicitly in the Last Call notice. That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents.

RFC 8068 Session Initiation Protocol (SIP) Recording Call Flows

Authors: R. Ravindranath, P. Ravindran, P. Kyzivat.

Date: February 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8068

Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer-protection reasons.The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows with metadata snapshots sent from a Session Recording Client(SRC) to a Session Recording Server (SRS).

RFC 8069 URN Namespace for IEEE

Authors: A. Thomas.

Date: February 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8069

This document describes the Namespace Identifier (NID) 'ieee' forUniform Resource Names (URNs) used to identify resources published by the Institute of Electrical and Electronics Engineers (IEEE). IEEE specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the IEEE Registration Authority.

RFC 8070 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension

Authors: M. Short, Ed., S. Moore, P. Miller.

Date: February 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8070

This document describes how to further extend the Public KeyCryptography for Initial Authentication in Kerberos (PKINIT) extension (defined in RFC 4556) to exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINITAuthentication Service (AS) exchange.

RFC 8071 NETCONF Call Home and RESTCONF Call Home

Authors: K. Watsen.

Date: February 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8071

This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client, respectively.

RFC 8072 YANG Patch Media Type

Authors: A. Bierman, M. Bjorklund, K. Watsen.

Date: February 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8072

This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language.

RFC 8073 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report

Authors: K. Moriarty, M. Ford.

Date: March 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8073

This report documents the discussions and conclusions from theCoordinating Attack Response at Internet Scale (CARIS) workshop that took place in Berlin, Germany on 18 June 2015. The purpose of this workshop was to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 8074 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario

Authors: J. Bi, G. Yao, J. Halpern, E. Levy-Abegnoli, Ed..

Date: February 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8074

In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods. This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods.

RFC 8075 Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)

Authors: A. Castellani, S. Loreto, A. Rahman, T. Fossati, E. Dijk.

Date: February 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8075

This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.

RFC 8076 A Usage for Shared Resources in RELOAD (ShaRe)

Authors: A. Knauf, T. Schmidt, Ed., G. Hege, M. Waehlisch.

Date: March 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8076

This document defines a REsource LOcation And Discovery (RELOAD)Usage for managing shared write access to RELOAD Resources. SharedResources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A newUSER-CHAIN-ACL access policy allows authorized peers to write aShared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name that is useful whenever peer-independent rendezvous processes are required.

RFC 8077 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)

Authors: L. Martini, Ed., G. Heron, Ed..

Date: February 2017

Formats: txt html json

Obsoletes: RFC 4447, RFC 6723

Also: STD 0084

Status: INTERNET STANDARD

DOI: 10.17487/RFC 8077

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 (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous OpticalNETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol(LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.
This document is a rewrite of RFC 4447 for publication as an InternetStandard.

RFC 8078 Managing DS Records from the Parent via CDS/CDNSKEY

Authors: O. Gudmundsson, P. Wouters.

Date: March 2017

Formats: txt json html

Updates: RFC 7344

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8078

RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevatesRFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.
Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.
This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).
It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record.

RFC 8079 Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs)

Authors: L. Miniero, S. Garcia Murillo, V. Pascual.

Date: February 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8079

SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just to intercept signalling. This means that B2BUAs often implement an RTP or RTP Control Protocol(RTCP) stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data.
This document defines the proper behaviour B2BUAs should follow when acting on both the signalling plane and media plane in order to preserve the end-to-end functionality of RTCP.

RFC 8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC

Authors: O. Sury, R. Edmonds.

Date: February 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8080

This document describes how to specify Edwards-curve Digital SecurityAlgorithm (EdDSA) keys and signatures in DNS Security (DNSSEC). It uses EdDSA with the choice of two curves: Ed25519 and Ed448.

RFC 8081 The "font" Top-Level Media Type

Authors: C. Lilley.

Date: February 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8081

This memo serves to register and document the "font" top-level media type, under which subtypes for representation formats for fonts may be registered. This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the "application" tree by their separate registrations.

RFC 8082 Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs

Authors: S. Wenger, J. Lennox, B. Burman, M. Westerlund.

Date: March 2017

Formats: txt html json

Updates: RFC 5104

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8082

This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full IntraRequest (FIR) description when using it with layered codecs. In particular, a decoder refresh point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found.

RFC 8083 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions

Authors: C. Perkins, V. Singh.

Date: March 2017

Formats: txt html json

Updates: RFC 3550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8083

The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactiveRTP flows.
This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by theseRTP circuit breaker algorithms.

RFC 8084 Network Transport Circuit Breakers

Authors: G. Fairhurst.

Date: March 2017

Formats: txt json html

Also: BCP 0208

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8084

This document explains what is meant by the term "network transportCircuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed.It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.

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 8086 GRE-in-UDP Encapsulation

Authors: L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert.

Date: March 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8086

This document specifies a method of encapsulating network protocol packets within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field.This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms.There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet.

RFC 8087 The Benefits of Using Explicit Congestion Notification (ECN)

Authors: G. Fairhurst, M. Welzl.

Date: March 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8087

The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit CongestionNotification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits whenECN is used over a network path that includes equipment that supportsCongestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices.

RFC 8088 How to Write an RTP Payload Format

Authors: M. Westerlund.

Date: May 2017

Formats: txt json html

Updates: RFC 2736

Status: INFORMATIONAL

DOI: 10.17487/RFC 8088

This document contains information on how best to write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions.

RFC 8089 The "file" URI Scheme

Authors: M. Kerwin.

Date: February 2017

Formats: txt json html

Updates: RFC 1738

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8089

This document provides a more complete specification of the "file"Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738.
It defines a common syntax that is intended to interoperate across the broad spectrum of existing usages. At the same time, it notes some other current practices around the use of file URIs.

RFC 8090 Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG)

Authors: R. Housley.

Date: February 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8090

This document outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names.

RFC 8091 A Media Type Structured Syntax Suffix for JSON Text Sequences

Authors: E. Wilde.

Date: February 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8091

Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+json-seq" as a structured syntax suffix for JSON text sequences.

RFC 8092 BGP Large Communities Attribute

Authors: J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard.

Date: February 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8092

This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all AutonomousSystem Numbers (ASNs) including four-octet ASNs.

RFC 8093 Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243

Authors: J. Snijders.

Date: February 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8093

This document requests IANA to mark BGP path attribute values 30, 31,129, 241, 242, and 243 as "Deprecated".

RFC 8094 DNS over Datagram Transport Layer Security (DTLS)

Authors: T. Reddy, D. Wing, P. Patil.

Date: February 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8094

DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.
This document proposes the use of Datagram Transport Layer Security(DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.

RFC 8095 Services Provided by IETF Transport Protocols and Congestion Control Mechanisms

Authors: G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed..

Date: March 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8095

This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines theTransmission Control Protocol (TCP), Multipath TCP, the StreamControl Transmission Protocol (SCTP), the User Datagram Protocol(UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), theInternet Control Message Protocol (ICMP), the Real-Time TransportProtocol (RTP), File Delivery over Unidirectional Transport /Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK-Oriented Reliable Multicast (NORM), Transport Layer Security (TLS),Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group.

RFC 8096 The IPv6-Specific MIB Modules Are Obsolete

Authors: B. Fenner.

Date: April 2017

Formats: txt html json

Obsoletes: RFC 2452, RFC 2454, RFC 2465, RFC 2466

Status: INFORMATIONAL

DOI: 10.17487/RFC 8096

In 2005-2006, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB, and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table. This document contains versions of the obsoletedIPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB, and IPV6-UDP-MIB modules for the purpose of updating MIB module repositories. This document obsoletes RFCs 2452, 2454, 2465, and 2466 (i.e., the RFCs containing these MIBs) and reclassifies them as Historic.

RFC 8097 BGP Prefix Origin Validation State Extended Community

Authors: P. Mohapatra, K. Patel, J. Scudder, D. Ward, R. Bush.

Date: March 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8097

This document defines a new BGP opaque extended community to carry the origination Autonomous System (AS) validation state inside an autonomous system. Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process.

RFC 8098 Message Disposition Notification

Authors: T. Hansen, Ed., A. Melnikov, Ed..

Date: February 2017

Formats: txt json html

Obsoletes: RFC 3798

Updates: RFC 2046, RFC 3461

Also: STD 0085

Status: INTERNET STANDARD

DOI: 10.17487/RFC 8098

This memo defines a MIME content type that may be used by a Mail UserAgent (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 header fields 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 are 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 multiprotocol 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.
This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461(Original-Recipient header field generation requirement).

RFC 8099 OSPF Topology-Transparent Zone

Authors: H. Chen, R. Li, A. Retana, Y. Yang, Z. Liu.

Date: February 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8099

This document presents a Topology-Transparent Zone (TTZ) in an OSPF area. A TTZ comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. A TTZ hides the internal topology of the TTZ from the outside. It does not directly advertise any internal information about the TTZ to a router outside of the TTZ. The information about the links and routers such as a link down inside the TTZ is not advertised to any router outside of the TTZ.

RFC 8100 Diffserv-Interconnection Classes and Practice

Authors: R. Geib, Ed., D. Black.

Date: March 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8100

This document defines a limited common set of Diffserv Per-HopBehaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at(inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operateMultiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation ofDiffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS.

RFC 8101 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service

Authors: C. Holmberg, J. Axell.

Date: March 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8101

This document creates additional Session Initiation Protocol (SIP)Resource-Priority namespaces to meet the requirements of the3GPP-defined Mission Critical Push To Talk (MCPTT) and places these namespaces in the corresponding IANA registry.

RFC 8102 Remote-LFA Node Protection and Manageability

Authors: P. Sarkar, Ed., S. Hegde, C. Bowers, H. Gredler, S. Litkowski.

Date: March 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8102

The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called "PQ-nodes") may not guarantee node protection for all destinations being protected by it.
This document describes an extension to the remote-loop-free-based IP fast reroute mechanisms that specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints.

RFC 8103 Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)

Authors: R. Housley.

Date: February 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8103

This document describes the conventions for using ChaCha20-Poly1305Authenticated Encryption in the Cryptographic Message Syntax (CMS).ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator.

RFC 8104 Pseudowire (PW) Endpoint Fast Failure Protection

Authors: Y. Shen, R. Aggarwal, W. Henderickx, Y. Jiang.

Date: March 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8104

This document specifies a fast mechanism for protecting pseudowires(PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure.

RFC 8105 Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)

Authors: P. Mariager, J. Petersen, Ed., Z. Shelby, M. Van de Logt, D. Barthel.

Date: May 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8105

Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy(ULE) is a low-power air interface technology that is proposed by theDECT Forum and is defined and specified by ETSI.
The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.
DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.
This document describes how IPv6 is transported over DECT ULE usingIPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.

RFC 8106 IPv6 Router Advertisement Options for DNS Configuration

Authors: J. Jeong, S. Park, L. Beloeil, S. Madanapalli.

Date: March 2017

Formats: txt html json

Obsoletes: RFC 6106

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8106

This document specifies IPv6 Router Advertisement (RA) options(called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.
This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.

RFC 8107 Advertising Digital Identifier (Ad-ID) URN Namespace Definition

Authors: J. Wold.

Date: March 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8107

Advertising Digital Identifiers (Ad-IDs) are used to identify advertising assets across all media platforms. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID)"adid" for Ad-IDs.

RFC 8108 Sending Multiple RTP Streams in a Single RTP Session

Authors: J. Lennox, M. Westerlund, Q. Wu, C. Perkins.

Date: March 2017

Formats: txt json html

Updates: RFC 3550, RFC 4585

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8108

This memo expands and clarifies the behavior of Real-time TransportProtocol (RTP) endpoints that use multiple synchronization sources(SSRCs). This occurs, for example, when an endpoint sends multipleRTP streams in a single RTP session. This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.

RFC 8109 Initializing a DNS Resolver with Priming Queries

Authors: P. Koch, M. Larson, P. Hoffman.

Date: March 2017

Formats: txt json html

Also: BCP 0209

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8109

This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers.

RFC 8110 Opportunistic Wireless Encryption

Authors: D. Harkins, Ed., W. Kumari, Ed..

Date: March 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8110

This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media.

RFC 8111 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)

Authors: V. Fuller, D. Lewis, V. Ermagan, A. Jain, A. Smirnov.

Date: May 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8111

This document describes the Locator/ID Separation Protocol DelegatedDatabase Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISPEndpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set ofLISP-speaking servers called "DDT nodes". Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.

RFC 8112 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG)

Authors: D. Farinacci, A. Jain, I. Kouvelas, D. Lewis.

Date: May 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8112

A simple tool called the Locator/ID Separation Protocol DelegatedDatabase Tree (LISP-DDT) Referral Internet Groper (RIG), also referred to in this document as "rig", can be used to query the LISP-DDT hierarchy. This document describes how the "rig" tool works.

RFC 8113 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations

Authors: M. Boucadair, C. Jacquenet.

Date: March 2017

Formats: txt html json

Obsoleted by: RFC 9304

Updates: RFC 6830

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8113

This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830.

RFC 8114 Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network

Authors: M. Boucadair, C. Qin, C. Jacquenet, Y. Lee, Q. Wang.

Date: March 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8114

This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to customers serviced byDual-Stack Lite (DS-Lite).

RFC 8115 DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes

Authors: M. Boucadair, J. Qin, T. Tsou, X. Deng.

Date: March 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8115

This document defines a Dynamic Host Configuration Protocol version 6(DHCPv6) Option for multicast IPv4 service continuity solutions, which is used to carry the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses.

RFC 8116 Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2)

Authors: T. Clausen, U. Herberg, J. Yi.

Date: May 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8116

This document analyzes common security threats to the Optimized LinkState Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated.

RFC 8117 Current Hostname Practice Considered Harmful

Authors: C. Huitema, D. Thaler, R. Winter.

Date: March 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8117

Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats.
There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values.

RFC 8118 The application/pdf Media Type

Authors: M. Hardy, L. Masinter, D. Markovic, D. Johnson, M. Bailey.

Date: March 2017

Formats: txt json html

Obsoletes: RFC 3778

Status: INFORMATIONAL

DOI: 10.17487/RFC 8118

The Portable Document Format (PDF) is an ISO standard (ISO32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993.This document provides an overview of the PDF format and updates the media type registration of "application/pdf". It obsoletes RFC 3778.

RFC 8119 SIP "cause" URI Parameter for Service Number Translation

Authors: M. Mohali, M. Barnes.

Date: March 2017

Formats: txt json html

Updates: RFC 4458

Status: INFORMATIONAL

DOI: 10.17487/RFC 8119

RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the UserAgent Server (UAS) receiving the message. This document updates RFC4458 by creating a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC 4458, for using the "cause" URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations.

RFC 8120 Mutual Authentication Protocol for HTTP

Authors: Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku.

Date: April 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8120

This document specifies an authentication scheme for the HypertextTransfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.

RFC 8121 Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)

Authors: Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku.

Date: April 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8121

This document specifies cryptographic algorithms for use with theMutual user authentication method for the Hypertext Transfer Protocol(HTTP).

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 8123 Requirements for Marking SIP Messages to be Logged

Authors: P. Dawes, C. Arunachalam.

Date: March 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8123

SIP networks use signaling monitoring tools to debug customer- reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between clients and, therefore, impractical to monitor SIP signaling end-to-end.
This document describes the requirements for adding an indicator to the SIP Protocol Data Unit (PDU) or a SIP message that marks the PDU as a candidate for logging. Such a marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such a marking can be carried end-to-end, including the SIP terminals, even if a session originates and terminates in different networks.

RFC 8124 The Session Description Protocol (SDP) WebSocket Connection URI Attribute

Authors: R. Ravindranath, G. Salgueiro.

Date: March 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8124

The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.

RFC 8125 Requirements for Password-Authenticated Key Agreement (PAKE) Schemes

Authors: J. Schmidt.

Date: April 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8125

Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password.This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group(CFRG).

RFC 8126 Guidelines for Writing an IANA Considerations Section in RFCs

Authors: M. Cotton, B. Leiba, T. Narten.

Date: June 2017

Formats: txt html json

Obsoletes: RFC 5226

Also: BCP 0026

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8126

Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).
To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.
This is the third edition of this document; it obsoletes RFC 5226.

RFC 8127 Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor

Authors: D. Patki, S. Gundavelli, J. Lee, Q. Fu, L. Bertz.

Date: August 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8127

This specification defines a new extension,LMA-Controlled-MAG-Session-Params, to Proxy Mobile IPv6. This option can be used by the local mobility anchor (LMA) in a Proxy Mobile IPv6 domain for signaling a mobile access gateway (MAG) on enforcing specific values for various configuration parameters such as heartbeat and binding refresh parameters.

RFC 8128 IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee

Authors: C. Morgan.

Date: March 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8128

This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).

RFC 8129 Authentication Indicator in Kerberos Tickets

Authors: A. Jain, N. Kinder, N. McCallum.

Date: March 2017

Formats: txt json html

Updates: RFC 4120

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8129

This document updates RFC 4120, as it specifies an extension in theKerberos protocol. It defines a new authorization data type,AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions.

RFC 8130 RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec

Authors: V. Demjanenko, D. Satterlee.

Date: March 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8130

This document describes the RTP payload format for the MixedExcitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frame sizes are supported. Comfort noise procedures and packet loss concealment are described in detail.

RFC 8131 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing

Authors: X. Zhang, H. Zheng, Ed., R. Gandhi, Ed., Z. Ali, P. Brzozowski.

Date: March 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8131

In non-packet transport networks, there are requirements where theGeneralized Multiprotocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ a restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs.
This document reviews how the LSP association is to be provided usingResource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of a GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures. No new signaling extensions are defined by this document, and it is strictly informative in nature.

RFC 8132 PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)

Authors: P. van der Stok, C. Bormann, A. Sehgal.

Date: April 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8132

The methods defined in RFC 7252 for the Constrained ApplicationProtocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.
This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.

RFC 8133 The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol

Authors: S. Smyshlyaev, Ed., E. Alekseev, I. Oshkin, V. Popov.

Date: March 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8133

This document describes the Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) protocol. The SESPAKE protocol provides password-authenticated key exchange for usage in systems for protection of sensitive information. The security proofs of the protocol were made for situations involving an active adversary in the channel, including man-in-the-middle (MitM) attacks and attacks based on the impersonation of one of the subjects.

RFC 8134 Management Incident Lightweight Exchange (MILE) Implementation Report

Authors: C. Inacio, D. Miyamoto.

Date: May 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8134

This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) andManagement Incident Lightweight Exchange (MILE) working groups.

RFC 8135 Complex Addressing in IPv6

Authors: M. Danielson, M. Nilsson.

Date: 1 April 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8135

The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world. It also allows for new and improved security measures and supports advanced cloud computing challenges.

RFC 8136 Additional Transition Functionality for IPv6

Authors: B. Carpenter, R. Hinden.

Date: 1 April 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8136

This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.

RFC 8137 IEEE 802.15.4 Information Element for the IETF

Authors: T. Kivinen, P. Kinney.

Date: May 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8137

IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15Assigned Numbers Authority (ANA) manages the registry of theInformation Elements. This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes.

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 8139 Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders

Authors: D. Eastlake 3rd, Y. Li, M. Umair, A. Banerjee, F. Hu.

Date: June 2017

Formats: txt json html

Obsoletes: RFC 6439

Updates: RFC 6325, RFC 7177

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8139

TRILL (Transparent Interconnection of Lots of Links) supports multi- access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multipleTRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates theAppointed Forwarder mechanism. It updates RFCs 6325 and 7177 and obsoletes RFC 6439.

RFC 8140 The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character

Authors: A. Farrel.

Date: 1 April 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8140

Ever since Gutenberg discovered and patented ASCII and the corresponding "Courier New" font with its now-famous "ten" point size, artisans and artificers have striven to represent their views of the world in print.
Similarly, starting from Darwin's discovery of the hippogriff and his subsequent registration of the creature as an International TradeMark, men (and some women) have struggled to catalog the fabulous variety that is called "nature".
This document supplies a number of representations of all manner of things (both elemental and hypothetical) supplied by some of our best collectors of curios and delivered in a manner that may well be reused by the cunning document author.

RFC 8141 Uniform Resource Names (URNs)

Authors: P. Saint-Andre, J. Klensin.

Date: April 2017

Formats: txt html json

Obsoletes: RFC 2141, RFC 3406

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8141

A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN- equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with theInternet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.

RFC 8142 GeoJSON Text Sequences

Authors: S. Gillies.

Date: April 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8142

This document describes the GeoJSON text sequence format and"application/geo+json-seq" media type. This format is based onJavaScript Object Notation (JSON) text sequences and GeoJSON, and it makes arbitrarily large geographic datasets incrementally parseable without restricting the form of GeoJSON texts within a sequence.

RFC 8143 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)

Authors: J. Elie.

Date: April 2017

Formats: txt json html

Updates: RFC 4642

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8143

This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport LayerSecurity (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. This document updates RFC 4642.

RFC 8144 Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV)

Authors: K. Murchison.

Date: April 2017

Formats: txt html json

Updates: RFC 7240

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8144

This document defines how the Prefer header field (RFC 7240) can be used by a Web Distributed Authoring and Versioning (WebDAV) client to request that certain behaviors be employed by a server while constructing a response to a request. Furthermore, it defines the new "depth-noroot" preference.
This document updates RFC 7240.

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 8146 Adding Support for Salted Password Databases to EAP-pwd

Authors: D. Harkins.

Date: April 2017

Formats: txt json html

Updates: RFC 5931

Status: INFORMATIONAL

DOI: 10.17487/RFC 8146

EAP-pwd is an Extensible Authentication Protocol (EAP) method that utilizes a shared password for authentication using a technique that is resistant to dictionary attacks. It includes support for raw keys and double hashing of a password in the style of Microsoft ChallengeHandshake Authentication Protocol version 2 (MSCHAPv2), but it does not include support for salted passwords. There are many existing databases of salted passwords, and it is desirable to allow their use with EAP-pwd.

RFC 8147 Next-Generation Pan-European eCall

Authors: R. Gellens, H. Tschofenig.

Date: May 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8147

This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan-European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data.
This document also registers MIME media types and an Emergency CallData Type for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests.
Although this specification is designed to meet the requirements of next-generation Pan-European eCall (NG-eCall), it is specified generically such that the technology can be reused or extended to suit requirements across jurisdictions.

RFC 8148 Next-Generation Vehicle-Initiated Emergency Calls

Authors: R. Gellens, B. Rosen, H. Tschofenig.

Date: May 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8148

This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident.Such calls are often referred to as "Automatic Crash Notification"(ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data.
This document also registers a MIME media type and Emergency CallData Type for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in SIP INFO requests. An external specification for the data format, contents, and structure is referenced in this document.
This document reuses the technical aspects of next-generation Pan-European eCall (a mandated and standardized system for emergency calls by in-vehicle systems (IVSs) within Europe and other regions).However, this document specifies use of a different set of vehicle(crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the IETF eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and it adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy(circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context.

RFC 8149 RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)

Authors: T. Saad, Ed., R. Gandhi, Ed., Z. Ali, R. Venator, Y. Kamite.

Date: April 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8149

The reoptimization of a Point-to-Multipoint (P2MP) TrafficEngineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break(MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point- to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.

RFC 8150 MPLS Transport Profile Linear Protection MIB

Authors: S. Kingston Smiler, M. Venkatesan, D. King, S. Aldrin, J. Ryoo.

Date: April 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8150

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing Multiprotocol Label Switching - TransportProfile (MPLS-TP) linear protection.

RFC 8151 Use Cases for Data Center Network Virtualization Overlay Networks

Authors: L. Yong, L. Dunbar, M. Toy, A. Isaac, V. Manral.

Date: May 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8151

This document describes Network Virtualization over Layer 3 (NVO3) use cases that can be deployed in various data centers and serve different data-center applications.

RFC 8152 CBOR Object Signing and Encryption (COSE)

Authors: J. Schaad.

Date: July 2017

Formats: txt json html

Obsoleted by: RFC 9052, RFC 9053

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8152

Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format.This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.

RFC 8153 Digital Preservation Considerations for the RFC Series

Authors: H. Flanagan.

Date: April 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8153

The RFC Editor is both the publisher and the archivist for the RFCSeries. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserveRFCs and describes the tools required to view or re-create RFCs as necessary. This document also highlights gaps in the current process and suggests compromises to balance cost with best practice.

RFC 8154 Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout

Authors: C. Hellwig.

Date: May 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8154

The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Small Computer System Interface (SCSI) layout type is defined in this document as an extension to pNFS to allow the use of SCSI-based block storage devices.

RFC 8155 Traversal Using Relays around NAT (TURN) Server Auto Discovery

Authors: P. Patil, T. Reddy, D. Wing.

Date: April 2017

Formats: txt html json

Updates: RFC 5766

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8155

Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise,ISP, or the network in which the client is located. Enterprises andISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms forTURN server discovery.
This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases.

RFC 8156 DHCPv6 Failover Protocol

Authors: T. Mrugalski, K. Kinnear.

Date: June 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8156

DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6(DHCPv6)" (RFC 3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC 7031).

RFC 8157 Huawei's GRE Tunnel Bonding Protocol

Authors: N. Leymann, C. Heidemann, M. Zhang, B. Sarikaya, M. Cullen.

Date: May 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8157

There is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single ServiceProvider, so that a single subscriber is provided with bonded access to heterogeneous connections at the same time.
In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for bonded access to a wired and a wireless network in customer premises, e.g., homes. In GRE TunnelBonding, two GRE tunnels, one per network connection, are set up and bonded together to form a single GRE tunnel for a subscriber.Compared with each subconnection, the bonded connections promise increased access capacity and improved reliability. The solution described in this document is currently implemented by Huawei and deployed by Deutsche Telekom AG. This document will enable other developers to build interoperable implementations.

RFC 8158 IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events

Authors: S. Sivakumar, R. Penno.

Date: December 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8158

Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that theNAT device is managing. In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior. This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information. This document describes the formats for logging NAT events.

RFC 8159 Keyed IPv6 Tunnel

Authors: M. Konstantynowicz, Ed., G. Heron, Ed., R. Schatzmayr, W. Henderickx.

Date: May 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8159

This document describes a tunnel encapsulation for Ethernet over IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on the Layer 2 Tunneling Protocol Version 3 (L2TPv3) over IP and does not use the L2TPv3 control plane.

RFC 8160 IUTF8 Terminal Mode in Secure Shell (SSH)

Authors: S. Tatham, D. Tucker.

Date: April 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8160

This document specifies a new opcode in the Secure Shell terminal modes encoding. The new opcode describes the widely used IUTF8 terminal mode bit, which indicates that terminal I/O uses UTF-8 character encoding.

RFC 8161 Benchmarking the Neighbor Discovery Protocol

Authors: W. Cerveny, R. Bonica, R. Thomas.

Date: May 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8161

This document provides benchmarking procedures for the NeighborDiscovery Protocol (NDP). It also proposes metrics by which an NDP implementation's scaling capabilities can be measured.

RFC 8162 Using Secure DNS to Associate Certificates with Domain Names for S/MIME

Authors: P. Hoffman, J. Schlyter.

Date: May 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8162

This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS.

RFC 8163 Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks

Authors: K. Lynn, Ed., J. Martocci, C. Neilson, S. Donaldson.

Date: May 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8163

Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.

RFC 8164 Opportunistic Security for HTTP/2

Authors: M. Nottingham, M. Thomson.

Date: May 2017

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 8164

This document describes how "http" URIs can be accessed usingTransport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https"URIs; it is vulnerable to active attacks.

RFC 8165 Design Considerations for Metadata Insertion

Authors: T. Hardie.

Date: May 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8165

The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications. This document considers the implications of protocol designs that associate metadata with encrypted flows. In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata.

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 8167 Bidirectional Remote Procedure Call on RPC-over-RDMA Transports

Authors: C. Lever.

Date: June 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8167

Minor versions of Network File System (NFS) version 4 newer than minor version 0 work best when Remote Procedure Call (RPC) transports can send RPC transactions in both directions on the same connection.This document describes how RPC transport endpoints capable of RemoteDirect Memory Access (RDMA) convey RPCs in both directions on a single connection.

RFC 8168 DHCPv6 Prefix-Length Hint Issues

Authors: T. Li, C. Liu, Y. Cui.

Date: May 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8168

DHCPv6 Prefix Delegation allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but it is unclear about how the client and server should act in different situations involving the prefix- length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations.

RFC 8169 Residence Time Measurement in MPLS Networks

Authors: G. Mirsky, S. Ruffini, E. Gray, J. Drake, S. Bryant, A. Vainshtein.

Date: May 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8169

This document specifies a new Generic Associated Channel (G-ACh) forResidence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain.
Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a PrecisionTime Protocol event message.

RFC 8170 Planning for Protocol Adoption and Subsequent Transitions

Authors: D. Thaler, Ed..

Date: May 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8170

Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.

RFC 8171 Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms

Authors: D. Eastlake 3rd, L. Dunbar, R. Perlman, Y. Li.

Date: June 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8171

This document describes mechanisms for providing directory service toTRILL (Transparent Interconnection of Lots of Links) edge switches.The directory information provided can be used in reducing multi- destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding. It can also be used to detect traffic with forged source addresses.

RFC 8172 Considerations for Benchmarking Virtual Network Functions and Their Infrastructure

Authors: A. Morton.

Date: July 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8172

The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in general-purpose hardware.

RFC 8173 Precision Time Protocol Version 2 (PTPv2) Management Information Base

Authors: V. Shankarkumar, L. Montini, T. Frost, G. Dowd.

Date: June 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8173

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in internets based on TCP or IP. In particular, it defines objects for managing networks using the Precision Time Protocol (PTP), specified in IEEE Std. 1588-2008.
This memo specifies a MIB module in a manner that is both compliant to the Structure of Management Information version 2 (SMIv2) and semantically identical to the peer SMIv1 definitions.

RFC 8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

Authors: B. Leiba.

Date: May 2017

Formats: txt html json

Updates: RFC 2119

Also: BCP 0014

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8174

RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

RFC 8175 Dynamic Link Exchange Protocol (DLEP)

Authors: S. Ratliff, S. Jury, D. Satterwhite, R. Taylor, B. Berry.

Date: June 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8175

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. This document introduces a new protocol called the Dynamic Link Exchange Protocol(DLEP), which provides a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics.

RFC 8176 Authentication Method Reference Values

Authors: M. Jones, P. Hunt, A. Nadalin.

Date: June 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8176

The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry forAuthentication Method Reference values and defines an initial set ofAuthentication Method Reference values.

RFC 8177 YANG Data Model for Key Chains

Authors: A. Lindem, Ed., Y. Qu, D. Yeung, I. Chen, J. Zhang.

Date: June 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8177

This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.

RFC 8178 Rules for NFSv4 Extensions and Minor Versions

Authors: D. Noveck.

Date: July 2017

Formats: txt html json

Updates: RFC 5661, RFC 7862

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8178

This document describes the rules relating to the extension of theNFSv4 family of protocols. It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as ProposedStandards. The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC 5661 and other RFCs defining minor versions.

RFC 8179 Intellectual Property Rights in IETF Technology

Authors: S. Bradner, J. Contreras.

Date: May 2017

Formats: txt html json

Obsoletes: RFC 3979, RFC 4879

Updates: RFC 2026

Also: BCP 0079

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8179

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 as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out 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 document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026.This document also obsoletes RFCs 3979 and 4879.

RFC 8180 Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration

Authors: X. Vilajosana, Ed., K. Pister, T. Watteyne.

Date: May 2017

Formats: txt html json

Also: BCP 0210

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8180

This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH providesIPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH-compliant devices.

RFC 8181 A Publication Protocol for the Resource Public Key Infrastructure (RPKI)

Authors: S. Weiler, A. Sonalker, R. Austein.

Date: July 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8181

This document defines a protocol for publishing Resource Public KeyInfrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects.Even in cases where a certificate issuer runs its own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol which addresses these needs.

RFC 8182 The RPKI Repository Delta Protocol (RRDP)

Authors: T. Bruijnzeels, O. Muravskiy, B. Weber, R. Austein.

Date: July 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8182

In the Resource Public Key Infrastructure (RPKI), CertificateAuthorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a newRPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an UpdateNotification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security(TLS)), and it enables the use of Content Distribution Networks(CDNs) or other caching infrastructures for the retrieval of these files.

RFC 8183 An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services

Authors: R. Austein.

Date: July 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8183

This note describes a simple out-of-band protocol to ease setup of the Resource Public Key Infrastructure (RPKI) provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication.
This setup protocol is not part of the provisioning or publication protocol; rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships.

RFC 8184 Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires

Authors: W. Cheng, L. Wang, H. Li, S. Davari, J. Dong.

Date: June 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8184

This document describes a framework and several scenarios for a pseudowire (PW) dual-homing local protection mechanism that avoids unnecessary switchovers and does not depend on whether a control plane is used. A Dual-Node Interconnection (DNI) PW is used to carry traffic between the dual-homing Provider Edge (PE) nodes when a failure occurs in one of the Attachment Circuits (AC) or PWs. ThisPW dual-homing local protection mechanism is complementary to existing PW protection mechanisms.

RFC 8185 Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection

Authors: W. Cheng, L. Wang, H. Li, J. Dong, A. D'Alessandro.

Date: June 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8185

In some scenarios, MPLS Transport Profile (MPLS-TP) pseudowires (PWs)(RFC 5921) may be statically configured when a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of an Attachment Circuit (AC), the failure of a Provider Edge (PE), or a failure in the PacketSwitched Network (PSN). The framework and typical scenarios of dual- homing PW local protection are described in RFC 8184. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs that is used for state exchange and switchover coordination between the dual- homing PEs for dual-homing PW local protection.

RFC 8186 Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)

Authors: G. Mirsky, I. Meilik.

Date: June 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8186

This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to theNetwork Time Protocol that is currently used.

RFC 8187 Indicating Character Encoding and Language for HTTP Header Field Parameters

Authors: J. Reschke.

Date: September 2017

Formats: txt json html

Obsoletes: RFC 5987

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8187

By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231.
This document obsoletes RFC 5987.

RFC 8188 Encrypted Content-Encoding for HTTP

Authors: M. Thomson.

Date: June 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8188

This memo introduces a content coding for HTTP that allows message payloads to be encrypted.

RFC 8189 Multi-Cost Application-Layer Traffic Optimization (ALTO)

Authors: S. Randriamasy, W. Roome, N. Schwan.

Date: October 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8189

The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.
This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics.

RFC 8190 Updates to the Special-Purpose IP Address Registries

Authors: R. Bonica, M. Cotton, B. Haberman, L. Vegoda.

Date: June 2017

Formats: txt html json

Updates: RFC 6890

Also: BCP 0153

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8190

This memo updates the IANA IPv4 and IPv6 Special-Purpose AddressRegistries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries.
This memo updates RFC 6890.

RFC 8191 Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)

Authors: Z. Yan, J. Lee, X. Lee.

Date: August 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8191

In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node(MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with theHNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations whenHNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.). In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification.

RFC 8192 Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases

Authors: S. Hares, D. Lopez, M. Zarny, C. Jacquenet, R. Kumar, J. Jeong.

Date: July 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8192

This document sets out the problem statement for Interface to NetworkSecurity Functions (I2NSF) and outlines some companion use cases.

RFC 8193 Information Model for Large-Scale Measurement Platforms (LMAPs)

Authors: T. Burbridge, P. Eardley, M. Bagnulo, J. Schoenwaelder.

Date: August 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8193

This Information Model applies to the Measurement Agent within anLMAP framework. As such, it outlines the information that is configured or preconfigured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol- and device-independent view of the Measurement Agent that can be implemented via one or more Control and Report Protocols.

RFC 8194 A YANG Data Model for LMAP Measurement Agents

Authors: J. Schoenwaelder, V. Bajpai.

Date: August 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8194

This document defines a data model for Large-Scale MeasurementPlatforms (LMAPs). The data model is defined using the YANG data modeling language.

RFC 8195 Use of BGP Large Communities

Authors: J. Snijders, J. Heasley, M. Schmidt.

Date: June 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8195

This document presents examples and inspiration for operator application of BGP Large Communities. Based on operational experience with BGP Communities, this document suggests logical categories of BGP Large Communities and demonstrates an orderly manner of organizing community values within them to achieve typical goals in routing policy. Any operator can consider using the concepts presented as the basis for their own BGP Large Communities repertoire.

RFC 8196 IS-IS Autoconfiguration

Authors: B. Liu, Ed., L. Ginsberg, B. Decraene, I. Farrer, M. Abrahamsson.

Date: July 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8196

This document specifies IS-IS autoconfiguration mechanisms. The key components are IS-IS System ID self-generation, duplication detection, and duplication resolution. These mechanisms provide limited IS-IS functions and are therefore suitable for networks where plug-and-play configuration is expected.

RFC 8197 A SIP Response Code for Unwanted Calls

Authors: H. Schulzrinne.

Date: July 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8197

This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted.SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.

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 8199 YANG Module Classification

Authors: D. Bogdanovic, B. Claise, C. Moberg.

Date: July 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8199

The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open-source software projects, vendors, and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules.
A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups.
This document describes a set of concepts and associated terms to support consistent classification of YANG modules.

RFC 8200 Internet Protocol, Version 6 (IPv6) Specification

Authors: S. Deering, R. Hinden.

Date: July 2017

Formats: txt html json

Obsoletes: RFC 2460

Also: STD 0086

Status: INTERNET STANDARD

DOI: 10.17487/RFC 8200

This document specifies version 6 of the Internet Protocol (IPv6).It obsoletes RFC 2460.

RFC 8201 Path MTU Discovery for IP version 6

Authors: J. McCann, S. Deering, J. Mogul, R. Hinden, Ed..

Date: July 2017

Formats: txt html json

Obsoletes: RFC 1981

Also: STD 0087

Status: INTERNET STANDARD

DOI: 10.17487/RFC 8201

This document describes Path MTU Discovery (PMTUD) for IP version 6.It is largely derived from RFC 1191, which describes Path MTUDiscovery for IP version 4. It obsoletes RFC 1981.

RFC 8202 IS-IS Multi-Instance

Authors: L. Ginsberg, S. Previdi, W. Henderickx.

Date: June 2017

Formats: txt json html

Obsoletes: RFC 6822

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8202

This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System toIntermediate System (IS-IS) routing protocol instances.
Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies.Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.
This document obsoletes RFC 6822.

RFC 8203 BGP Administrative Shutdown Communication

Authors: J. Snijders, J. Heitz, J. Scudder.

Date: July 2017

Formats: txt json html

Obsoleted by: RFC 9003

Updates: RFC 4486

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8203

This document enhances the BGP Cease NOTIFICATION message"Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486.

RFC 8204 Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV)

Authors: M. Tahhan, B. O'Mahony, A. Morton.

Date: September 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8204

This memo describes the contributions of the Open Platform for NFV(OPNFV) project on Virtual Switch Performance (VSPERF), particularly in the areas of test setups and configuration parameters for the system under test. This project has extended the current and completed work of the Benchmarking Methodology Working Group in theIETF and references existing literature. The BenchmarkingMethodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. Therefore, this memo describes the additional considerations when virtual switches are implemented on general-purpose hardware. The expanded tests and benchmarks are also influenced by the OPNFV mission to support virtualization of the"telco" infrastructure.

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 8206 BGPsec Considerations for Autonomous System (AS) Migration

Authors: W. George, S. Murphy.

Date: September 2017

Formats: txt json html

Updates: RFC 8205

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8206

This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol.

RFC 8207 BGPsec Operational Considerations

Authors: R. Bush.

Date: September 2017

Formats: txt json html

Also: BCP 0211

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8207

Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. Operational practices are expected to evolve as BGPsec is formalized and initially deployed.

RFC 8208 BGPsec Algorithms, Key Formats, and Signature Formats

Authors: S. Turner, O. Borchert.

Date: September 2017

Formats: txt html json

Obsoleted by: RFC 8608

Updates: RFC 7935

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8208

This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure").
This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.

RFC 8209 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests

Authors: M. Reynolds, S. Turner, S. Kent.

Date: September 2017

Formats: txt html json

Updates: RFC 6487

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8209

This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the BorderGateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in theInternet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure(RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends theRPKI; therefore, this document updates the RPKI Resource CertificatesProfile (RFC 6487).

RFC 8210 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1

Authors: R. Bush, R. Austein.

Date: September 2017

Formats: txt html json

Updates: RFC 6810

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8210

In order to verifiably validate the origin Autonomous Systems andAutonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure(RFC 6480) prefix origin data and router keys from a trusted cache.This document describes a protocol to deliver them.
This document describes version 1 of the RPKI-Router protocol. RFC6810 describes version 0. This document updates RFC 6810.

RFC 8211 Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)

Authors: S. Kent, D. Ma.

Date: September 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8211

This document analyzes actions by or against a CertificationAuthority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by RelyingParties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data.

RFC 8212 Default External BGP (EBGP) Route Propagation Behavior without Policies

Authors: J. Mauch, J. Snijders, G. Hankins.

Date: July 2017

Formats: txt json html

Updates: RFC 4271

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8212

This document updates RFC 4271 by defining the default behavior of aBGP speaker when there is no Import or Export Policy associated with an External BGP session.

RFC 8213 Security of Messages Exchanged between Servers and Relay Agents

Authors: B. Volz, Y. Pal.

Date: August 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8213

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6(DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption. With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4.

RFC 8214 Virtual Private Wire Service Support in Ethernet VPN

Authors: S. Boutros, A. Sajassi, S. Salam, J. Drake, J. Rabadan.

Date: August 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8214

This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks.EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.

RFC 8215 Local-Use IPv4/IPv6 Translation Prefix

Authors: T. Anderson.

Date: August 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8215

This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms.

RFC 8216 HTTP Live Streaming

Authors: R. Pantos, Ed., W. May.

Date: August 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8216

This document describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients(receivers) of the streams. It describes version 7 of this protocol.

RFC 8217 Clarifications for When to Use the name-addr Production in SIP Messages

Authors: R. Sparks.

Date: August 2017

Formats: txt json html

Updates: RFC 3261, RFC 3325, RFC 3515, RFC 3892, RFC 4508, RFC 5002, RFC 5318, RFC 5360, RFC 5502

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8217

RFC 3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately, it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative.
This document updates RFC 3261 to state the constraint generically and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates the RFCs that define extension SIP header fields using the alternative to clarify that the constraint applies (RFCs 3325,3515, 3892, 4508, 5002, 5318, 5360, and 5502).

RFC 8218 Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)

Authors: J. Yi, B. Parrein.

Date: August 2017

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8218

This document specifies a multipath extension for the Optimized LinkState Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures. The interoperability with OLSRv2 is retained.

RFC 8219 Benchmarking Methodology for IPv6 Transition Technologies

Authors: M. Georgescu, L. Pislaru, G. Lencse.

Date: August 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8219

Benchmarking methodologies that address the performance of network interconnect devices that are IPv4- or IPv6-capable exist, but theIPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be tested using the recommendations of RFCs 2544 and 5180. The methodology also includes a metric for benchmarking load scalability.

RFC 8220 Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS)

Authors: O. Dornon, J. Kotalwar, V. Hemige, R. Qiu, Z. Zhang.

Date: September 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8220

This document describes the procedures and recommendations forVirtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying.
With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIMJoin/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstreamJoin/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain.
This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices.

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 8222 Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery

Authors: A. Sullivan.

Date: September 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8222

Despite its name, DNS-Based Service Discovery (DNS-SD) can use naming systems other than DNS when looking for services. Moreover, when it uses DNS, DNS-SD uses the full capability of DNS, rather than using a subset of available octets. This is of particular relevance where some environments use DNS labels that conform to InternationalizedDomain Names for Applications (IDNA), and other environments use labels containing Unicode characters (such as containing octets corresponding to characters encoded as UTF-8). In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for the selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner.

RFC 8223 Application-Aware Targeted LDP

Authors: S. Esale, R. Torvi, L. Jalil, U. Chunduri, K. Raza.

Date: August 2017

Formats: txt json html

Updates: RFC 7473

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8223

Recent Targeted Label Distribution Protocol (tLDP) applications, such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires, may automatically establish a tLDP session with anyLabel Switching Router (LSR) in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate the TargetedApplication Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications.In addition, each targeted application is mapped to LDP ForwardingEquivalence Class (FEC) elements to advertise only necessary LDP FEC label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC label bindings over the session.

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 8225 PASSporT: Personal Assertion Token

Authors: C. Wendt, J. Peterson.

Date: February 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8225

This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.

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 8227 MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology

Authors: W. Cheng, L. Wang, H. Li, H. van Helvoort, J. Dong.

Date: August 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8227

This document describes requirements, architecture, and solutions forMPLS-TP Shared-Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switching (RPS) protocol that is used to coordinate the protection behavior of the nodes on an MPLS ring.

RFC 8228 Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels

Authors: A. Freytag.

Date: August 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8228

Rules for validating identifier labels and alternate representations of those labels (variants) are known as Label Generation Rulesets(LGRs); they are used for the implementation of identifier systems such as Internationalized Domain Names (IDNs). This document describes ways to design LGRs to support variant labels. In designing LGRs, it is important to ensure that the label generation rules are consistent and well behaved in the presence of variants.The design decisions can then be expressed using the XML representation of LGRs that is defined in RFC 7940.

RFC 8229 TCP Encapsulation of IKE and IPsec Packets

Authors: T. Pauly, S. Touati, R. Mantha.

Date: August 2017

Formats: txt html json

Obsoleted by: RFC 9329

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8229

This document describes a method to transport Internet Key ExchangeProtocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and EncapsulatingSecurity Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.

RFC 8230 Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages

Authors: M. Jones.

Date: September 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8230

The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary ObjectRepresentation (CBOR). This specification defines algorithm encodings and representations enabling RSA algorithms to be used forCOSE messages. Encodings are specified for the use of RSAProbabilistic Signature Scheme (RSASSA-PSS) signatures, RSAEncryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and RSA keys.

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 8232 Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE

Authors: E. Crabbe, I. Minei, J. Medved, R. Varga, X. Zhang, D. Dhody.

Date: September 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8232

A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol(IGP) but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires aState Synchronization mechanism between the PCE and the network, thePCE and Path Computation Clients (PCCs), and cooperating PCEs. The basic mechanism for State Synchronization is part of the stateful PCE specification. This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions.

RFC 8233 Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)

Authors: D. Dhody, Q. Wu, V. Manral, Z. Ali, K. Kumaki.

Date: September 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8233

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.
IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element CommunicationProtocol (PCEP) provides mechanisms for Path Computation Elements(PCEs) to perform path computations in response to Path ComputationClient (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation.

RFC 8234 Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode

Authors: J. Ryoo, T. Cheung, H. van Helvoort, I. Busi, G. Wen.

Date: August 2017

Formats: txt html json

Updates: RFC 7271

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8234

This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) ControlLogic (in which the state machine resides) when operating in APS mode and clarify the operation related to state transition table lookup.

RFC 8235 Schnorr Non-interactive Zero-Knowledge Proof

Authors: F. Hao, Ed..

Date: September 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8235

This document describes the Schnorr non-interactive zero-knowledge(NIZK) proof, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value. It can serve as a useful building block for many cryptographic protocols to ensure that participants follow the protocol specification honestly. This document specifies the SchnorrNIZK proof in both the finite field and the elliptic curve settings.

RFC 8236 J-PAKE: Password-Authenticated Key Exchange by Juggling

Authors: F. Hao, Ed..

Date: September 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8236

This document specifies a Password-Authenticated Key Exchange byJuggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party.

RFC 8237 MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs

Authors: L. Martini, G. Swallow, E. Bellagamba.

Date: October 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8237

This document describes a method for generating an aggregated pseudowire (PW) status message transmitted for a statically configured PW on a Multiprotocol Label Switching (MPLS) LabelSwitched Path (LSP) to indicate the status of one or more PWs carried on the LSP.
The method for transmitting the PW status information is not new; however, this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP.

RFC 8238 Data Center Benchmarking Terminology

Authors: L. Avramov, J. Rapp.

Date: August 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8238

The purposes of this informational document are to establish definitions and describe measurement techniques for data center benchmarking, as well as to introduce new terminology applicable to performance evaluations of data center network equipment. This document establishes the important concepts for benchmarking network switches and routers in the data center and is a prerequisite for the test methodology document (RFC 8239). Many of these terms and methods may be applicable to network equipment beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.

RFC 8239 Data Center Benchmarking Methodology

Authors: L. Avramov, J. Rapp.

Date: August 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8239

The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. RFC 8238 is a prerequisite for this document, as it contains terminology that is considered normative. Many of these terms and methods may be applicable beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.

RFC 8240 Report from the Internet of Things Software Update (IoTSU) Workshop 2016

Authors: H. Tschofenig, S. Farrell.

Date: September 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8240

This document provides a summary of the Internet of Things SoftwareUpdate (IoTSU) Workshop that took place at Trinity College Dublin,Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices.This report summarizes the discussions and lists recommendations to the standards community.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 8241 Interface to the Routing System (I2RS) Security-Related Requirements

Authors: S. Hares, D. Migault, J. Halpern.

Date: September 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8241

This document presents security-related requirements for theInterface to the Routing System (I2RS) protocol, which provides a new interface to the routing system described in the I2RS architecture document (RFC 7921). The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them.One such reuse is of the security features of a secure transport(e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol,Datagram TLS (DTLS)) such as encryption, message integrity, mutual peer authentication, and anti-replay protection. The new I2RS features to consider from a security perspective are as follows: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier that identifies an application using theI2RS client, and an extremely constrained read-only non-secure transport.

RFC 8242 Interface to the Routing System (I2RS) Ephemeral State Requirements

Authors: J. Haas, S. Hares.

Date: September 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8242

"An Architecture for the Interface to the Routing System" (RFC 7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) that any protocol suite attempting to meet the needs of the Interface to the Routing System(I2RS) protocol has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol.

RFC 8243 Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)

Authors: R. Perlman, D. Eastlake 3rd, M. Zhang, A. Ghanwani, H. Zhai.

Date: September 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8243

Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network? Or can they merely be unique within each multilevel area?
This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability; it makes recommendations in some cases.

RFC 8244 Special-Use Domain Names Problem Statement

Authors: T. Lemon, R. Droms, W. Kumari.

Date: October 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8244

The policy defined in RFC 6761 for IANA registrations in the"Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.
This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic ofSpecial-Use Domain Names.

RFC 8245 Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444

Authors: T. Clausen, C. Dearlove, U. Herberg, H. Rogge.

Date: October 2017

Formats: txt json html

Updates: RFC 5444

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8245

RFC 5444 specifies a generalized Mobile Ad Hoc Network (MANET) packet/message format and describes an intended use for multiplexedMANET routing protocol messages; this use is mandated by RFC 5498 when using the MANET port or protocol number that it specifies. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals and that would have led to interoperability problems, to the impediment of protocol extension development, and/or to an inability to use optional generic parsers.

RFC 8246 HTTP Immutable Responses

Authors: P. McManus.

Date: September 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8246

The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.

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 8248 Security Automation and Continuous Monitoring (SACM) Requirements

Authors: N. Cam-Winget, L. Lorenzin.

Date: September 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8248

This document defines the scope and set of requirements for theSecurity Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols. The requirements and scope are based on the agreed-upon use cases described in RFC 7632.

RFC 8249 Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation

Authors: M. Zhang, X. Zhang, D. Eastlake 3rd, R. Perlman, S. Chatterjee.

Date: September 2017

Formats: txt json html

Updates: RFC 6325, RFC 7177, RFC 7780

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8249

The base IETF TRILL (Transparent Interconnection of Lots of Links) protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 and 7177, that assures that link-state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets. This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. This document updates RFCs 6325,7177, and 7780.

RFC 8250 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option

Authors: N. Elkins, R. Hamilton, M. Ackermann.

Date: September 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8250

To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) DestinationOptions header. The field limits, calculations, and usage in measurement of PDM are included in this document.

RFC 8251 Updates to the Opus Audio Codec

Authors: JM. Valin, K. Vos.

Date: October 2017

Formats: txt json html

Updates: RFC 6716

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8251

This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the normative decoder implementation included in Appendix A of RFC 6716.The changes fix real and potential security-related issues, as well as minor quality-related issues.

RFC 8252 OAuth 2.0 for Native Apps

Authors: W. Denniss, J. Bradley.

Date: October 2017

Formats: txt html json

Updates: RFC 6749

Also: BCP 0212

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8252

OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.

RFC 8253 PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)

Authors: D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody.

Date: October 2017

Formats: txt html json

Updates: RFC 5440

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8253

The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path ComputationClient (PCC) and a Path Computation Element (PCE), or among PCEs.This document describes PCEPS -- the usage of Transport LayerSecurity (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.
This document updates RFC 5440 in regards to the PCEP initialization phase procedures.

RFC 8254 Uniform Resource Name (URN) Namespace Registration Transition

Authors: J. Klensin, J. Hakala.

Date: October 2017

Formats: txt json html

Obsoletes: RFC 3044, RFC 3187

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8254

The original registration procedure for formal Uniform Resource Name(URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed by RFC 8141, which adopts a different model, focusing on encouraging registration and publication of information for all appropriate namespaces. This document clarifies the status of relevant olderRFCs and confirms and documents advice to IANA about selected existing registrations. This document also obsoletes RFCs 3044 and3187 and moves them to Historic status. These RFCs describe the ISSN and ISBN namespaces, which are now outdated because the descriptions reside in registration templates.

RFC 8255 Multiple Language Content Type

Authors: N. Tomkinson, N. Borenstein.

Date: October 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8255

This document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions(MIME) standard. This content type makes it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings.

RFC 8256 Requirements for Hitless MPLS Path Segment Monitoring

Authors: A. D'Alessandro, L. Andersson, S. Ueno, K. Arai, Y. Koike.

Date: October 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8256

One of the most important Operations, Administration, and Maintenance(OAM) capabilities for transport-network operation is fault localization. An in-service, on-demand path segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between endpoints.However, the current segment monitoring approach defined for MPLS(including the MPLS Transport Profile (MPLS-TP)) in RFC 6371"Operations, Administration, and Maintenance Framework for MPLS-BasedTransport Networks" has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of newOAM tools to support Hitless Path Segment Monitoring (HPSM).

RFC 8257 Data Center TCP (DCTCP): TCP Congestion Control for Data Centers

Authors: S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd.

Date: October 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8257

This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends theExplicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales theTCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures.

RFC 8258 Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI)

Authors: D. Ceccarelli, L. Berger.

Date: October 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8258

This document defines a generic information structure for information carried in routing protocol Interface Switching Capability Descriptor(ISCD) Switching Capability Specific Information (SCSI) fields. This"Generalized SCSI" can be used with routing protocols that defineGMPLS ISCDs and any specific technology. This document does not modify any existing technology-specific formats and is defined for use in conjunction with new GMPLS Switching Capability types. The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture and associated protocol standards.

RFC 8259 The JavaScript Object Notation (JSON) Data Interchange Format

Authors: T. Bray, Ed..

Date: December 2017

Formats: txt json html

Obsoletes: RFC 7159

Also: STD 0090

Status: INTERNET STANDARD

DOI: 10.17487/RFC 8259

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance.

RFC 8260 Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol

Authors: R. Stewart, M. Tuexen, S. Loreto, R. Seggelmann.

Date: November 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8260

The Stream Control Transmission Protocol (SCTP) is a message-oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head-of-line blocking at the sender. The interleaving of user messages is required for WebRTC data channels.
Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, or not implement, user message interleaving.

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 8262 Content-ID Header Field in the Session Initiation Protocol (SIP)

Authors: C. Holmberg, I. Sedlacek.

Date: October 2017

Formats: txt html json

Updates: RFC 5621, RFC 5368, RFC 6442

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8262

This document specifies the Content-ID header field for usage in theSession Initiation Protocol (SIP). This document also updates RFC5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables aContent-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields.
This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field.

RFC 8263 Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message

Authors: B. Weis, U. Mangla, T. Karl, N. Maheshwari.

Date: November 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8263

The Group Domain of Interpretation (GDOI) includes the ability of aGroup Controller/Key Server (GCKS) to provide a set of current GroupMember (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request that the GM devices return an acknowledgement of receipt of its rekey message and specifies the acknowledgement method.

RFC 8264 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols

Authors: P. Saint-Andre, M. Blanchet.

Date: October 2017

Formats: txt json html

Obsoletes: RFC 7564

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8264

Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known asStringprep (RFC 3454). This document obsoletes RFC 7564.

RFC 8265 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords

Authors: P. Saint-Andre, A. Melnikov.

Date: October 2017

Formats: txt json html

Obsoletes: RFC 7613

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8265

This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454).The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613.

RFC 8266 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames

Authors: P. Saint-Andre.

Date: October 2017

Formats: txt html json

Obsoletes: RFC 7700

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8266

This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames","display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700.

RFC 8267 Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1

Authors: C. Lever.

Date: October 2017

Formats: txt html json

Obsoletes: RFC 5667

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8267

This document specifies Upper-Layer Bindings of Network File System(NFS) protocol versions to RPC-over-RDMA version 1, thus enabling the use of Direct Data Placement. This document obsoletes RFC 5667.

RFC 8268 More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)

Authors: M. Baushke.

Date: December 2017

Formats: txt json html

Updates: RFC 4250, RFC 4253

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8268

This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key.

RFC 8269 The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)

Authors: W. Kim, J. Lee, J. Park, D. Kwon, D. Kim.

Date: October 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8269

This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR and GCM) and the SRTP key derivation functions for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and Multimedia Internet KEYing (MIKEY) parameter sets for use with ARIA.

RFC 8270 Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits

Authors: L. Velvindron, M. Baushke.

Date: December 2017

Formats: txt json html

Updates: RFC 4419

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8270

The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) transport-layer protocol specifies that servers and clients should support groups with a minimum modulus group size of 1024 bits.Recent security research has shown that the minimum value of 1024 bits is insufficient to protect against state-sponsored actors and any organization with enough computing resources. This RFC updatesRFC 4419, which allowed for DH moduli less than 2048 bits; now, 2048 bits is the minimum acceptable group size.

RFC 8271 Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)

Authors: M. Taillon, T. Saad, Ed., R. Gandhi, Ed., Z. Ali, M. Bhatia.

Date: October 2017

Formats: txt json html

Updates: RFC 4090

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8271

This document updates the Resource Reservation Protocol - TrafficEngineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC4090 to support Packet Switch Capable (PSC) Generalized MultiprotocolLabel Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the redirection of bidirectional traffic onto bypass tunnels that ensure the co-routing of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in the control plane.

RFC 8272 TinyIPFIX for Smart Meters in Constrained Networks

Authors: C. Schmitt, B. Stiller, B. Trammell.

Date: November 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8272

This document specifies the TinyIPFIX protocol that is used for transmitting smart-metering data in constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, RFC 4944).TinyIPFIX is derived from IP Flow Information Export (RFC 7011) and adopted to the needs of constrained networks. This document specifies how the TinyIPFIX Data and Template Records are transmitted in constrained networks such as 6LoWPAN and how TinyIPFIX data can be converted into data that is not TinyIPFIX in a proxy device.

RFC 8273 Unique IPv6 Prefix per Host

Authors: J. Brzozowski, G. Van de Velde.

Date: December 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8273

This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments.

RFC 8274 Incident Object Description Exchange Format Usage Guidance

Authors: P. Kampanakis, M. Suzuki.

Date: November 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8274

The Incident Object Description Exchange Format (IODEF) v2 (RFC 7970) defines a data representation that provides a framework for sharing information about computer security incidents commonly exchanged byComputer Security Incident Response Teams (CSIRTs). Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for security practitioners to develop tools that leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It addresses how common security indicators can be represented in IODEF and provides use cases of how IODEF is being used. This document aims to make IODEF's adoption by vendors easier and to encourage faster and wider adoption of the model by CSIRTs around the world.

RFC 8275 Allowing Inheritable NFSv4 Access Control Entries to Override the Umask

Authors: J. Fields, A. Gruenbacher.

Date: December 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8275

In many environments, inheritable NFSv4 Access Control Entries (ACEs) can be rendered ineffective by the application of the per-process file mode creation mask (umask). This can be addressed by transmitting the umask and create mode as separate pieces of data, allowing the server to make more intelligent decisions about the permissions to set on new files. This document proposes a protocol extension to accomplish that.

RFC 8276 File System Extended Attributes in NFSv4

Authors: M. Naik, M. Eshel.

Date: December 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8276

This document describes an optional feature extending the NFSv4 protocol. This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients. Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories. Such support is present in many modern local file systems. New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects.

RFC 8277 Using BGP to Bind MPLS Labels to Address Prefixes

Authors: E. Rosen.

Date: October 2017

Formats: txt html json

Obsoletes: RFC 3107

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8277

This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label(or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer ReachabilityInformation field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107.

RFC 8278 Mobile Access Gateway (MAG) Multipath Options

Authors: P. Seite, A. Yegin, S. Gundavelli.

Date: January 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8278

This specification defines extensions to the Proxy Mobile IPv6(PMIPv6) protocol that allow a mobile access gateway (MAG) to register more than one proxy care-of address (pCoA) with the local mobility anchor (LMA) and to simultaneously establish multiple IP tunnels with the LMA. This capability allows the MAG to utilize all the available access networks to route the mobile node's IP traffic.This document defines the following two new mobility header options: the MAG Multipath Binding option and the MAG Identifier option.

RFC 8279 Multicast Using Bit Index Explicit Replication (BIER)

Authors: IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, T. Przygienda, S. Aldrin.

Date: November 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8279

This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state.This architecture is known as "Bit Index Explicit Replication"(BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in aBIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree- building protocols results in a considerable simplification.

RFC 8280 Research into Human Rights Protocol Considerations

Authors: N. ten Oever, C. Cath.

Date: October 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8280

This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed.
This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights ProtocolConsiderations (HRPC) Research Group and also by individuals from outside the research group.

RFC 8281 Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model

Authors: E. Crabbe, I. Minei, S. Sivabalan, R. Varga.

Date: December 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8281

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.
The extensions for stateful PCE provide active control ofMultiprotocol Label Switching (MPLS) Traffic Engineering LabelSwitched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to thePCE. This document describes the creation and deletion ofPCE-initiated LSPs under the stateful PCE model.

RFC 8282 Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering

Authors: E. Oki, T. Takeda, A. Farrel, F. Zhang.

Date: December 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8282

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) networks.
MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.
The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering.

RFC 8283 An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control

Authors: A. Farrel, Ed., Q. Zhao, Ed., Z. Li, C. Zhou.

Date: December 2017

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8283

The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.
PCE was developed to derive paths for MPLS Label Switched Paths(LSPs), which are supplied to the head end of the LSP using the PathComputation Element Communication Protocol (PCEP).
SDN has a broader applicability than signaled MPLS traffic-engineered(TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service FunctionChaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.
This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability forPCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.
This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.

RFC 8284 Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages

Authors: S. Kille.

Date: November 2017

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8284

The Extensible Messaging and Presence Protocol (XMPP) identifies users by use of Jabber IDs (JIDs). The Lightweight Directory AccessProtocol (LDAP) enables provision of a white pages service with a schema relating to users and support for Internet protocols. This specification defines a schema to enable XMPP JIDs to be associated with objects in an LDAP directory so that this information can be used with white pages applications.

RFC 8285 A General Mechanism for RTP Header Extensions

Authors: D. Singer, H. Desineni, R. Even, Ed..

Date: October 2017

Formats: txt json html

Obsoletes: RFC 5285

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8285

This document provides a general mechanism to use the header extension feature of RTP (the Real-time Transport Protocol). It provides the option to use a small number of small extensions in eachRTP packet, where the universe of possible extensions is large and registration is decentralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC 5285.

RFC 8286 RTP/RTCP Extension for RTP Splicing Notification

Authors: J. Xia, R. Even, R. Huang, L. Deng.

Date: October 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8286

Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and that delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing.
This memo defines two RTP/RTCP extensions to indicate the splicing- related information to the splicer: an RTP header extension that conveys the information "in band" and an RTP Control Protocol (RTCP) packet that conveys the information out of band.

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 8288 Web Linking

Authors: M. Nottingham.

Date: October 2017

Formats: txt json html

Obsoletes: RFC 5988

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8288

This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships("link relation types").
It also defines the serialisation of such links in HTTP headers with the Link header field.

RFC 8289 Controlled Delay Active Queue Management

Authors: K. Nichols, V. Jacobson, A. McGregor, Ed., J. Iyengar, Ed..

Date: January 2018

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8289

This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments.

RFC 8290 The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm

Authors: T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, E. Dumazet.

Date: January 2018

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8290

This memo presents the FQ-CoDel hybrid packet scheduler and ActiveQueue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency.
FQ-CoDel mixes packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short, and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware.

RFC 8291 Message Encryption for Web Push

Authors: M. Thomson.

Date: November 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8291

This document describes a message encryption scheme for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an application server to a user agent.

RFC 8292 Voluntary Application Server Identification (VAPID) for Web Push

Authors: M. Thomson, P. Beverloo.

Date: November 2017

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8292

An application server can use the Voluntary Application ServerIdentification (VAPID) method described in this document to voluntarily identify itself to a push service. The "vapid" authentication scheme allows a client to include its identity in a signed token with requests that it makes. The signature can be used by the push service to attribute requests that are made by the same application server to a single entity. The identification information can allow the operator of a push service to contact the operator of the application server. The signature can be used to restrict the use of a push message subscription to a single application server.

RFC 8293 A Framework for Multicast in Network Virtualization over Layer 3

Authors: A. Ghanwani, L. Dunbar, M. McBride, V. Bannai, R. Krishnan.

Date: January 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8293

This document provides a framework for supporting multicast traffic in a network that uses Network Virtualization over Layer 3 (NVO3).Both infrastructure multicast and application-specific multicast are discussed. It describes the various mechanisms that can be used for delivering such traffic as well as the data plane and control plane considerations for each of the mechanisms.

RFC 8294 Common YANG Data Types for the Routing Area

Authors: X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger.

Date: December 2017

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8294

This document defines a collection of common data types using theYANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.

RFC 8295 EST (Enrollment over Secure Transport) Extensions

Authors: S. Turner.

Date: January 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8295

The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI(Public Key Infrastructure) services, namely certificate enrollment(e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys.This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScriptObject Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services.

RFC 8296 Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks

Authors: IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, J. Tantsura, S. Aldrin, I. Meilik.

Date: January 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8296

Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.

RFC 8297 An HTTP Status Code for Indicating Hints

Authors: K. Oku.

Date: December 2017

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8297

This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.

RFC 8298 Self-Clocked Rate Adaptation for Multimedia

Authors: I. Johansson, Z. Sarker.

Date: December 2017

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8298

This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a LongTerm Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios.

RFC 8299 YANG Data Model for L3VPN Service Delivery

Authors: Q. Wu, Ed., S. Litkowski, L. Tomotaki, K. Ogaki.

Date: January 2018

Formats: txt json html

Obsoletes: RFC 8049

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8299

This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.
This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to theYANG module and some clarifications to the text.

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 8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)

Authors: S. Kitterman.

Date: January 2018

Formats: txt json html

Updates: RFC 6376

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8301

The cryptographic algorithm and key size requirements included whenDomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms.

RFC 8302 Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization

Authors: Y. Li, D. Eastlake 3rd, L. Dunbar, R. Perlman, M. Umair.

Date: January 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8302

This document describes mechanisms to optimize the Address ResolutionProtocol (ARP) and Neighbor Discovery (ND) traffic in a TransparentInterconnection of Lots of Links (TRILL) campus. TRILL switches maintain a cache of IP / Media Access Control (MAC) address / DataLabel bindings that are learned from ARP/ND requests and responses that pass through them. In many cases, this cache allows an edgeRouting Bridge (RBridge) to avoid flooding an ARP/ND request by either responding to it directly or encapsulating it and unicasting it. Such optimization reduces packet flooding over a TRILL campus.

RFC 8303 On the Usage of Transport Features Provided by IETF Transport Protocols

Authors: M. Welzl, M. Tuexen, N. Khademi.

Date: February 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8303

This document describes how the transport protocols TransmissionControl Protocol (TCP), MultiPath TCP (MPTCP), Stream ControlTransmission Protocol (SCTP), User Datagram Protocol (UDP), andLightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services(TAPS) API.

RFC 8304 Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)

Authors: G. Fairhurst, T. Jones.

Date: February 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8304

This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols.

RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency

Authors: D. Schinazi, T. Pauly.

Date: December 2017

Formats: txt json html

Obsoletes: RFC 6555

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8305

Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.

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 8307 Well-Known URIs for the WebSocket Protocol

Authors: C. Bormann.

Date: January 2018

Formats: txt html json

Updates: RFC 6455

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8307

RFC 5785 defines a path prefix, "/.well-known/", that can be used by well-known URIs. It was specifically defined for the "http" and"https" URI schemes. The present memo formally updates RFC 6455, which defines the URI schemes defined for the WebSocket Protocol, to extend the use of these well-known URIs to those URI schemes.

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 8309 Service Models Explained

Authors: Q. Wu, W. Liu, A. Farrel.

Date: January 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8309

The IETF has produced many modules in the YANG modeling language.The majority of these modules are used to construct data models to model devices or monolithic functions.
A small number of YANG modules have been defined to model services(for example, the Layer 3 Virtual Private Network Service Model(L3SM) produced by the L3SM working group and documented in RFC8049).
This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.

RFC 8310 Usage Profiles for DNS over TLS and DNS over DTLS

Authors: S. Dickinson, D. Gillmor, T. Reddy.

Date: March 2018

Formats: txt json html

Updates: RFC 7858

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8310

This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over TransportLayer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to aDNS server. Additionally, it defines (D)TLS protocol profiles forDNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858.

RFC 8311 Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation

Authors: D. Black.

Date: January 2018

Formats: txt json html

Updates: RFC 3168, RFC 4341, RFC 4342, RFC 5622, RFC 6679

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8311

This memo updates RFC 3168, which specifies Explicit CongestionNotification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. AnExperimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341,4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.

RFC 8312 CUBIC for Fast Long-Distance Networks

Authors: I. Rhee, L. Xu, S. Ha, A. Zimmermann, L. Eggert, R. Scheffenegger.

Date: February 2018

Formats: txt html json

Obsoleted by: RFC 9438

Status: INFORMATIONAL

DOI: 10.17487/RFC 8312

CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC.

RFC 8313 Use of Multicast across Inter-domain Peering Points

Authors: P. Tarapore, Ed., R. Sayko, G. Shepherd, T. Eckert, Ed., R. Krishnan.

Date: January 2018

Formats: txt html json

Also: BCP 0213

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8313

This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process.

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 8315 Cancel-Locks in Netnews Articles

Authors: M. Baeuerle.

Date: February 2018

Formats: txt json html

Updates: RFC 5537

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8315

This document defines an extension to the Netnews Article Format that may be used to authenticate the withdrawal of existing articles.This document updates RFC 5537.

RFC 8316 Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations

Authors: J. Nobre, L. Granville, A. Clemm, A. Gonzalez Prieto.

Date: February 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8316

This document describes an experimental use case that employs autonomic networking for the monitoring of Service Level Agreements(SLAs). The use case is for detecting violations of SLAs in a distributed fashion. It strives to optimize and dynamically adapt the autonomic deployment of active measurement probes in a way that maximizes the likelihood of detecting service-level violations with a given resource budget to perform active measurements. This optimization and adaptation should be done without any outside guidance or intervention.
This document is a product of the IRTF Network Management ResearchGroup (NMRG). It is published for informational purposes.

RFC 8317 Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)

Authors: A. Sajassi, Ed., S. Salam, J. Drake, J. Uttaro, S. Boutros, J. Rabadan.

Date: January 2018

Formats: txt html json

Updates: RFC 7385

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8317

The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol LabelSwitching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432,"BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796,"Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service(VPLS)". This document makes use of the most significant bit of theTunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly.

RFC 8318 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee

Authors: S. Dawkins.

Date: January 2018

Formats: txt json html

Obsoleted by: RFC 8713

Updates: RFC 7437

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8318

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 8319 Support for Adjustable Maximum Router Lifetimes per Link

Authors: S. Krishnan, J. Korhonen, S. Chakrabarti, E. Nordmark, A. Yourtchenko.

Date: February 2018

Formats: txt json html

Updates: RFC 4861

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8319

The IPv6 Neighbor Discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements(RAs) from a router interface as well as the maximum router lifetime.It also allows the limits to be overridden by documents that are specific to the link layer. This document allows for overriding these values on a per-link basis.
This document specifies updates to the IPv6 Neighbor DiscoveryProtocol (RFC 4861) to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime.

RFC 8320 LDP Extensions to Support Maximally Redundant Trees

Authors: A. Atlas, K. Tiruveedhula, C. Bowers, J. Tantsura, IJ. Wijnands.

Date: February 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8320

This document specifies extensions to the Label Distribution Protocol(LDP) to support the creation of Label Switched Paths (LSPs) forMaximally Redundant Trees (MRTs). A prime use of MRTs is for unicast and multicast IP/LDP Fast Reroute, which we will refer to as"MRT-FRR".
The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for Label Switching Routers (LSRs) andLabel Edge Routers (LERs) advertising the MRT Capability.
MRT-FRR uses LDP multi-topology extensions, so three multi-topologyIDs have been allocated from the MPLS MT-ID space.

RFC 8321 Alternate-Marking Method for Passive and Hybrid Performance Monitoring

Authors: G. Fioccola, Ed., A. Capello, M. Cociglio, L. Castaldelli, M. Chen, L. Zheng, G. Mirsky, T. Mizrahi.

Date: January 2018

Formats: txt json html

Obsoleted by: RFC 9341

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8321

This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on anAlternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application.

RFC 8322 Resource-Oriented Lightweight Information Exchange (ROLIE)

Authors: J. Field, S. Banghart, D. Waltermire.

Date: February 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8322

This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources.Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories. This specification extends the AtomPublishing Protocol and Atom Syndication Format to transport and share security automation resource representations.

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 8324 DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?

Authors: J. Klensin.

Date: February 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8324

The basic design of the Domain Name System was completed almost 30 years ago. The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way.

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 8326 Graceful BGP Session Shutdown

Authors: P. Francois, Ed., B. Decraene, Ed., C. Pelsser, K. Patel, C. Filsfils.

Date: March 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8326

This document standardizes a new well-known BGP community,GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths. This document also describes operational procedures that use this well-known community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g., for planned maintenance.

RFC 8327 Mitigating the Negative Impact of Maintenance through BGP Session Culling

Authors: W. Hargrave, M. Griswold, J. Snijders, N. Hilliard.

Date: March 2018

Formats: txt html json

Also: BCP 0214

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8327

This document outlines an approach to mitigate the negative impact on networks resulting from maintenance activities. It includes guidance for both IP networks and Internet Exchange Points (IXPs). The approach is to ensure BGP-4 sessions that will be affected by maintenance are forcefully torn down before the actual maintenance activities commence.

RFC 8328 Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA)

Authors: W. Liu, C. Xie, J. Strassner, G. Karagiannis, M. Klyus, J. Bi, Y. Cheng, D. Zhang.

Date: March 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8328

The Simplified Use of Policy Abstractions (SUPA) policy-based management framework defines base YANG data models to encode policy.These models point to device-, technology-, and service-specific YANG data models developed elsewhere. Policy rules within an operator's environment can be used to express high-level, possibly network-wide, policies to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services. This document describes the SUPA basic framework, its elements, and interfaces.

RFC 8329 Framework for Interface to Network Security Functions

Authors: D. Lopez, E. Lopez, L. Dunbar, J. Strassner, R. Kumar.

Date: February 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8329

This document describes the framework for Interface to NetworkSecurity Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF. Network Security Functions(NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated.

RFC 8330 OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth

Authors: H. Long, M. Ye, G. Mirsky, A. D'Alessandro, H. Shah.

Date: February 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8330

A network may contain links with variable discrete bandwidth, e.g., microwave and copper. The bandwidth of such links may change discretely in response to a changing external environment. The word"availability" is typically used to describe such links during network planning. This document defines a new type of GeneralizedSwitching Capability-Specific Information (SCSI) TLV to extend theGeneralized Multiprotocol Label Switching (GMPLS) Open Shortest PathFirst (OSPF) routing protocol. The extension can be used for route computation in a network that contains links with variable discrete bandwidth. Note that this document only covers the mechanisms by which the availability information is distributed. The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document. It is intended that technology-specific documents will reference this document to describe specific uses.

RFC 8331 RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data

Authors: T. Edwards.

Date: February 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8331

This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers(SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1.SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD).

RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol

Authors: D. Bider.

Date: March 2018

Formats: txt html json

Updates: RFC 4252, RFC 4253

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8332

This memo updates RFCs 4252 and 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections.

RFC 8333 Micro-loop Prevention by Introducing a Local Convergence Delay

Authors: S. Litkowski, B. Decraene, C. Filsfils, P. Francois.

Date: March 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8333

This document describes a mechanism for link-state routing protocols that prevents local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence.
Because this mechanism delays the IGP convergence, it may only be used for planned maintenance or when Fast Reroute (FRR) protects the traffic during the time between the link failure and the IGP convergence.
The mechanism is limited to the link-down event in order to keep the mechanism simple.
Simulations using real network topologies have been performed and show that local loops are a significant portion (&rt;50%) of the total forwarding loops.

RFC 8334 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)

Authors: J. Gould, W. Tan, G. Brown.

Date: March 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8334

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry.

RFC 8335 PROBE: A Utility for Probing Interfaces

Authors: R. Bonica, R. Thomas, J. Linkova, C. Lenart, M. Boucadair.

Date: February 2018

Formats: txt json html

Updates: RFC 4884

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8335

This document describes a network diagnostic tool called PROBE.PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884.

RFC 8336 The ORIGIN HTTP/2 Frame

Authors: M. Nottingham, E. Nygren.

Date: March 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8336

This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.

RFC 8337 Model-Based Metrics for Bulk Transport Capacity

Authors: M. Mathis, A. Morton.

Date: March 2018

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8337

This document introduces a new class of Model-Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance.
Model-Based Metrics rely on mathematical models to specify a TargetedIP Diagnostic Suite, a set of IP diagnostic tests designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path.
For Bulk Transport Capacity, the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (e.g., bursts) mimics TCP or other transport protocols carrying bulk data over a long path. However, they are constructed to be independent of the details of the subpath under test, end systems, or applications. Likewise, the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the TargetTransport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications.

RFC 8338 Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP

Authors: S. Boutros, Ed., S. Sivabalan, Ed..

Date: March 2018

Formats: txt json html

Updates: RFC 7385

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8338

This document specifies a mechanism to signal Point-to-Multipoint(P2MP) Pseudowire (PW) trees using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP orMPLS-enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updates RFC 7385 by reassigning the reserved value 0xFF to be the wildcard transport tunnel type.

RFC 8339 Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms

Authors: P. Jain, Ed., S. Boutros, S. Aldrin.

Date: March 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8339

Label Switched Path (LSP) Ping is a widely deployed Operation,Administration, and Maintenance (OAM) mechanism in MPLS networks.This document describes a mechanism to verify connectivity of Point- to-Multipoint (P2MP) Pseudowires (PWs) using LSP Ping.

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 8341 Network Configuration Access Control Model

Authors: A. Bierman, M. Bjorklund.

Date: March 2018

Formats: txt html json

Obsoletes: RFC 6536

Also: STD 0091

Status: INTERNET STANDARD

DOI: 10.17487/RFC 8341

The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.
This document obsoletes RFC 6536.

RFC 8342 Network Management Datastore Architecture (NMDA)

Authors: M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton.

Date: March 2018

Formats: txt json html

Updates: RFC 7950

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8342

Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF.This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.

RFC 8343 A YANG Data Model for Interface Management

Authors: M. Bjorklund.

Date: March 2018

Formats: txt json html

Obsoletes: RFC 7223

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8343

This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document.The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342.
This document obsoletes RFC 7223.

RFC 8344 A YANG Data Model for IP Management

Authors: M. Bjorklund.

Date: March 2018

Formats: txt html json

Obsoletes: RFC 7277

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8344

This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state.
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture defined in RFC 8342.
This document obsoletes RFC 7277.

RFC 8345 A YANG Data Model for Network Topologies

Authors: A. Clemm, J. Medved, R. Varga, N. Bahadur, H. Ananthakrishnan, X. Liu.

Date: March 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8345

This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.

RFC 8346 A YANG Data Model for Layer 3 Topologies

Authors: A. Clemm, J. Medved, R. Varga, X. Liu, H. Ananthakrishnan, N. Bahadur.

Date: March 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8346

This document defines a YANG data model for Layer 3 network topologies.

RFC 8347 A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)

Authors: X. Liu, Ed., A. Kyparlis, R. Parikh, A. Lindem, M. Zhang.

Date: March 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8347

This document describes a data model for the Virtual RouterRedundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered.

RFC 8348 A YANG Data Model for Hardware Management

Authors: A. Bierman, M. Bjorklund, J. Dong, D. Romascanu.

Date: March 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8348

This document defines a YANG data model for the management of hardware on a single server.

RFC 8349 A YANG Data Model for Routing Management (NMDA Version)

Authors: L. Lhotka, A. Lindem, Y. Qu.

Date: March 2018

Formats: txt html json

Obsoletes: RFC 8022

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8349

This document specifies three YANG modules and one submodule.Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, RoutingInformation Bases (RIBs), and control-plane protocols.
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA). This document obsoletes RFC 8022.

RFC 8350 Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP)

Authors: R. Zhang, R. Pazhyannur, S. Gundavelli, Z. Cao, H. Deng, Z. Du.

Date: April 2018

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8350

Control and Provisioning of Wireless Access Points (CAPWAP) is a protocol for encapsulating a station's data frames between theWireless Transmission Point (WTP) and Access Controller (AC).Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP DataChannel is used for tunneling. In many deployments, encapsulating data frames to an entity other than the AC (for example, to an AccessRouter (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and theAccess Router. This document defines an extension to the CAPWAP protocol that supports this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process, and the AC may select one of the supported alternate tunnel encapsulation types while configuring theWTP.

RFC 8351 The PKCS #8 EncryptedPrivateKeyInfo Media Type

Authors: S. Leonard.

Date: June 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8351

This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8. An instance of this media type carries a single encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value.

RFC 8352 Energy-Efficient Features of Internet of Things Protocols

Authors: C. Gomez, M. Kovatsch, H. Tian, Z. Cao, Ed..

Date: April 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8352

This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges. It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper-layer protocols so that they can together achieve an energy-efficient behavior. The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks.

RFC 8353 Generic Security Service API Version 2: Java Bindings Update

Authors: M. Upadhyay, S. Malkani, W. Wang.

Date: May 2018

Formats: txt json html

Obsoletes: RFC 5653

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8353

The Generic Security Services Application Programming Interface(GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2: Java Bindings Update"(RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fail, it has a chance to emit an error token that can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version.
The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2,Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined forGSS-API are "The Simple Public-Key GSS-API Mechanism (SPKM)"(RFC 2025) and "The Kerberos Version 5 Generic Security ServiceApplication Program Interface (GSS-API) Mechanism: Version 2"(RFC 4121).

RFC 8354 Use Cases for IPv6 Source Packet Routing in Networking (SPRING)

Authors: J. Brzozowski, J. Leddy, C. Filsfils, R. Maglione, Ed., M. Townsley.

Date: March 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8354

The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing can be used to steer packets through anIPv6 or MPLS network using the source routing paradigm. This document illustrates some use cases for Segment Routing in anIPv6-only environment.

RFC 8355 Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks

Authors: C. Filsfils, Ed., S. Previdi, Ed., B. Decraene, R. Shakir.

Date: March 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8355

This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on SourcePacket Routing in Networking (SPRING) networks.

RFC 8356 Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)

Authors: D. Dhody, D. King, A. Farrel.

Date: March 2018

Formats: txt json html

Updates: RFC 5440

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8356

IANA assigns values to the Path Computation Element CommunicationProtocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries forPCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review.
This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use.

RFC 8357 Generalized UDP Source Port for DHCP Relay

Authors: N. Shen, E. Chen.

Date: March 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8357

This document defines an extension to the DHCP protocols that allows a relay agent to use any available source port for upstream communications. The extension also allows inclusion of a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications.

RFC 8358 Update to Digital Signatures on Internet-Draft Documents

Authors: R. Housley.

Date: March 2018

Formats: txt html json

Updates: RFC 5485

Status: INFORMATIONAL

DOI: 10.17487/RFC 8358

RFC 5485 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.
The RFC Editor recently published the first RFC that includes non-ASCII characters in a text file. The conventions specified in RFC7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.
This document updates RFC 5485.

RFC 8359 Network-Assigned Upstream Label

Authors: X. Zhang, Ed., V. Beeram, Ed., I. Bryskin, D. Ceccarelli, O. Gonzalez de Dios.

Date: March 2018

Formats: txt html json

Updates: RFC 3471, RFC 3473, RFC 6205

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8359

This document discusses a Generalized Multi-Protocol Label Switching(GMPLS) Resource reSerVation Protocol with Traffic Engineering(RSVP-TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFCs 3471, 3473, and 6205 as it defines processing for a special label value in the UPSTREAM_LABEL object.

RFC 8360 Resource Public Key Infrastructure (RPKI) Validation Reconsidered

Authors: G. Huston, G. Michaelson, C. Martinez, T. Bruijnzeels, A. Newton, D. Shaw.

Date: April 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8360

This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource PublicKey Infrastructure (RPKI), while retaining essential security features.
The procedure specified in RFC 6487 requires that ResourceCertificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing CertificationAuthority (CA) to chose to communicate that such ResourceCertificates should be accepted for the intersection of their resources and the issuing certificate.
It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.
This choice is signaled by a set of alternative Object Identifiers(OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers"(RFC 3779) and "Certificate Policy (CP) for the Resource Public KeyInfrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.
Furthermore, this document provides an alternative to Route OriginAuthorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsecPKI Profiles -- publication requested) validation.

RFC 8361 Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic

Authors: W. Hao, Y. Li, M. Durrani, S. Gupta, A. Qu.

Date: April 2018

Formats: txt html json

Updates: RFC 6325

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8361

In Transparent Interconnection of Lots of Links (TRILL) active-active access, a Reverse Path Forwarding (RPF) check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781. This document describes a solution to resolve this RPF check failure issue through centralized replication. All ingress Routing Bridges(RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established per the TRILL base protocol (RFC 6325).To avoid RPF check failure on an RBridge sitting between the ingressRBridge and the centralized replication node, some change in the RPF calculation algorithm is required. RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge. This document updates RFC 6325.

RFC 8362 OSPFv3 Link State Advertisement (LSA) Extensibility

Authors: A. Lindem, A. Roy, D. Goethals, V. Reddy Vallem, F. Baker.

Date: April 2018

Formats: txt json html

Updates: RFC 5340, RFC 5838

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8362

OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described inRFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separateLSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information inType-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.
This document updates RFC 5340, "OSPF for IPv6", and RFC 5838,"Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.

RFC 8363 GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks

Authors: X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. Ceccarelli.

Date: May 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8363

The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its RecommendationsG.694.1 and G.872 to include a new Dense Wavelength DivisionMultiplexing (DWDM) grid by defining channel spacings, a set of nominal central frequencies, and the concept of the "frequency slot".Corresponding techniques for data-plane connections are known as"flexi-grid".
Based on the characteristics of flexi-grid defined in G.694.1 and inRFCs 7698 and 7699, this document describes the Open Shortest PathFirst - Traffic Engineering (OSPF-TE) extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid.

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 8365 A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)

Authors: A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar, J. Uttaro, W. Henderickx.

Date: March 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8365

This document specifies how Ethernet VPN (EVPN) can be used as aNetwork Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on theEVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN),Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to GenericNetwork Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifiesEVPN route constructions for VXLAN/NVGRE encapsulations andAutonomous System Border Router (ASBR) procedures for multihoming ofNetwork Virtualization Edge (NVE) devices.

RFC 8366 A Voucher Artifact for Bootstrapping Protocols

Authors: K. Watsen, M. Richardson, M. Pritikin, T. Eckert.

Date: May 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8366

This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".
This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax(CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer(i.e., the Manufacturer Authorized Signing Authority (MASA)).
This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.

RFC 8367 Wrongful Termination of Internet Protocol (IP) Packets

Authors: T. Mizrahi, J. Yallouz.

Date: 1 April 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8367

Routers and middleboxes terminate packets for various reasons. In some cases, these packets are wrongfully terminated. This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them.

RFC 8368 Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)

Authors: T. Eckert, Ed., M. Behringer.

Date: May 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8368

Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.
Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.
This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies.

RFC 8369 Internationalizing IPv6 Using 128-Bit Unicode

Authors: H. Kaplan.

Date: 1 April 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8369

It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed. Assuming ISO and the UnicodeConsortium follow the practices of the IETF, the next Unicode code point size will be 128 bits. This document describes how this future128-bit Unicode can be leveraged to improve IPv6 adoption and finally bring internationalization support to IPv6.

RFC 8370 Techniques to Improve the Scalability of RSVP-TE Deployments

Authors: V. Beeram, Ed., I. Minei, R. Shakir, D. Pacella, T. Saad.

Date: May 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8370

Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number ofLSPs deployed.
This document defines two techniques, Refresh-Interval IndependentRSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in LabelSwitching Routers (LSRs) and hence allow implementations to support larger scale deployments.

RFC 8371 Mobile Node Identifier Types for MIPv6

Authors: C. Perkins, V. Devarapalli.

Date: July 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8371

This document defines additional identifier type numbers for use with the mobile node identifier option for Mobile IPv6 (MIPv6) as defined by RFC 4283.

RFC 8372 MPLS Flow Identification Considerations

Authors: S. Bryant, C. Pignataro, M. Chen, Z. Li, G. Mirsky.

Date: May 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8372

This document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user 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 8374 BGPsec Design Choices and Summary of Supporting Discussions

Authors: K. Sriram, Ed..

Date: April 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8374

This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification).The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the arguments that aided the decision process. Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETFSIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes.

RFC 8375 Special-Use Domain 'home.arpa.'

Authors: P. Pfister, T. Lemon.

Date: May 2018

Formats: txt html json

Updates: RFC 7788

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8375

This document specifies the behavior that is expected from the DomainName System with regard to DNS queries for names ending with'.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.

RFC 8376 Low-Power Wide Area Network (LPWAN) Overview

Authors: S. Farrell, Ed..

Date: May 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8376

Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set ofLPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of runningIP in LPWANs.

RFC 8377 Transparent Interconnection of Lots of Links (TRILL): Multi-Topology

Authors: D. Eastlake 3rd, M. Zhang, A. Banerjee.

Date: July 2018

Formats: txt json html

Updates: RFC 6325, RFC 7177

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8377

This document specifies extensions to the IETF TRILL (TransparentInterconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS(Intermediate System to Intermediate System) multi-topology specified in RFC 5120. This document updates RFCs 6325 and 7177.

RFC 8378 Signal-Free Locator/ID Separation Protocol (LISP) Multicast

Authors: V. Moreno, D. Farinacci.

Date: May 2018

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8378

When multicast sources and receivers are active at Locator/IDSeparation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites.

RFC 8379 OSPF Graceful Link Shutdown

Authors: S. Hegde, P. Sarkar, H. Gredler, M. Nanduri, L. Jalil.

Date: May 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8379

When a link is being prepared to be taken out of service, the traffic needs to be diverted from both ends of the link. Increasing the metric to the highest value on one side of the link is not sufficient to divert the traffic flowing in the other direction.
It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to be able to advertise a link as being in a graceful-shutdown state to indicate impending maintenance activity on the link. This information can be used by the network devices to reroute the traffic effectively.
This document describes the protocol extensions to disseminate graceful-link-shutdown information in OSPFv2 and OSPFv3.

RFC 8380 Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation

Authors: L. Dunbar, D. Eastlake 3rd, R. Perlman.

Date: May 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8380

This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection ofLots of Links) encapsulation with assistance from a directory service.

RFC 8381 Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol

Authors: D. Eastlake 3rd, Y. Li, W. Hao, A. Banerjee.

Date: May 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8381

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol is implemented by devices called TRILL switches or RBridges(Routing Bridges). TRILL includes a general mechanism, called anRBridge Channel, for the transmission of typed messages betweenRBridges in the same campus and between RBridges and end stations on the same link. This document specifies a method to send vendor- specific messages over the RBridge Channel facility.

RFC 8382 Shared Bottleneck Detection for Coupled Congestion Control for RTP Media

Authors: D. Hayes, Ed., S. Ferlin, M. Welzl, K. Hiorth.

Date: June 2018

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8382

This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed.

RFC 8383 Transparent Interconnection of Lots of Links (TRILL): Address Flush Message

Authors: W. Hao, D. Eastlake 3rd, Y. Li, M. Umair.

Date: May 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8383

The TRILL (Transparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane.In particular, it learns local Media Access Control (MAC) addresses and the edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and the edge switch port of attachment from the decapsulation of remotely sourced TRILL Data packets.
This document specifies a message by which a TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets.This is a supplement to the TRILL automatic address forgetting (seeSection 4.8.3 of RFC 6325) and can assist in achieving more rapid convergence in case of topology or configuration change.

RFC 8384 Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes

Authors: R. Perlman, F. Hu, D. Eastlake 3rd, T. Liao.

Date: July 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8384

This document addresses the problem of the size and freshness of the endnode learning table in edge Routing Bridges (RBridges), by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "SmartEndnode". Only the attached edge RBridge can distinguish a "SmartEndnode" from a "normal endnode". The Smart Endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames. The solution also enables endnodes that areFine-Grained Label (FGL) aware.

RFC 8385 Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS

Authors: M. Umair, S. Kingston Smiler, D. Eastlake 3rd, L. Yong.

Date: June 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8385

This document specifies methods to interconnect multiple TRILL(Transparent Interconnection of Lots of Links) sites with an intervening MPLS network using existing TRILL and VPLS (VirtualPrivate LAN Service) standards. This document addresses two problems: 1) providing connection between more than two TRILL sites that are separated by an MPLS provider network and 2) providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network.

RFC 8386 Privacy Considerations for Protocols Relying on IP Broadcast or Multicast

Authors: R. Winter, M. Faath, F. Weisshaar.

Date: May 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8386

A number of application-layer protocols make use of IP broadcast or multicast messages for functions such as local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcast or multicast messages, a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze their content.Therefore, designers of protocols that make use of broadcast or multicast messages need to take special care when designing their protocols.

RFC 8387 Practical Considerations and Implementation Experiences in Securing Smart Object Networks

Authors: M. Sethi, J. Arkko, A. Keranen, H. Back.

Date: May 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8387

This memo describes challenges associated with securing resource- constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for resource-constrained devices, and presents some preliminary experiences with those libraries for message signing on resource- constrained devices. Lastly, the memo discusses trade-offs involving different types of security approaches.

RFC 8388 Usage and Applicability of BGP MPLS-Based Ethernet VPN

Authors: J. Rabadan, Ed., S. Palislamovic, W. Henderickx, A. Sajassi, J. Uttaro.

Date: May 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8388

This document discusses the usage and applicability of BGP MPLS-basedEthernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained in the example scenario along with the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks.

RFC 8389 Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E)

Authors: Y. Fu, S. Jiang, B. Liu, J. Dong, Y. Chen.

Date: December 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8389

This memo defines a portion of the Management Information Base (MIB) for Mapping of Address and Port with Encapsulation (MAP-E) for use with network management protocols.

RFC 8390 RSVP-TE Path Diversity Using Exclude Route

Authors: Z. Ali, Ed., G. Swallow, Ed., F. Zhang, Ed., D. Beller, Ed..

Date: July 2018

Formats: txt html json

Updates: RFC 4874

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8390

RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A typical LSP diversity use case is for protection, where two LSPs should follow different paths through the network in order to avoid single points of failure, thus greatly improving service availability. This document specifies an approach that can be used for network scenarios where the full path(s) is not necessarily known by use of an abstract identifier for the path. Three types of abstract identifiers are specified: client based, Path Computation Element (PCE) based, and network based. This document specifies two new diversity subobjects for the RSVP eXclude Route Object (XRO) and the Explicit ExclusionRoute Subobject (EXRS).
For the protection use case, LSPs are typically created at a slow rate and exist for a long time so that it is reasonable to assume that a given (reference) path currently existing (with a well-known identifier) will continue to exist and can be used as a reference when creating the new diverse path. Re-routing of the existing(reference) LSP, before the new path is established, is not considered.

RFC 8391 XMSS: eXtended Merkle Signature Scheme

Authors: A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A. Mohaisen.

Date: May 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8391

This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifiesWinternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block.XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks.Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers.

RFC 8392 CBOR Web Token (CWT)

Authors: M. Jones, E. Wahlstroem, S. Erdtman, H. Tschofenig.

Date: May 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8392

CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR ObjectSigning and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token(JWT) but uses CBOR rather than JSON.

RFC 8393 Operating the Network Service Header (NSH) with Next Protocol "None"

Authors: A. Farrel, J. Drake.

Date: May 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8393

This document describes a network that supports Service FunctionChaining (SFC) using the Network Service Header (NSH) with no payload data and carrying only metadata. This is achieved by defining a newNSH "Next Protocol" type value of "None".
This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case.

RFC 8394 Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements

Authors: Y. Li, D. Eastlake 3rd, L. Kreeger, T. Narten, D. Black.

Date: May 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8394

In the Split Network Virtualization Edge (Split-NVE) architecture, the functions of the NVE are split across a server and a piece of external network equipment that is called an "External NVE". The server-resident control-plane functionality resides in control software, which may be part of hypervisor or container-management software; for simplicity, this document refers to the hypervisor as the "location" of this software.
One or more control-plane protocols between a hypervisor and its associated External NVE(s) are used by the hypervisor to distribute its virtual-machine networking state to the External NVE(s) for further handling. This document illustrates the functionality required by this type of control-plane signaling protocol and outlines the high-level requirements. Virtual-machine states as well as state transitioning are summarized to help clarify the protocol requirements.

RFC 8395 Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels

Authors: K. Patel, S. Boutros, J. Liste, B. Wen, J. Rabadan.

Date: June 2018

Formats: txt html json

Updates: RFC 4761

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8395

This document defines protocol extensions required to synchronize flow label states among Provider Edges (PEs) when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer 2 Virtual Private Networks(L2VPNs). This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community.

RFC 8396 Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework

Authors: J. Peterson, T. McGarry.

Date: July 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8396

The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, includingTelephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used byInternet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of theInternet environment and proposes a framework for Internet-based services relying on TNs.

RFC 8397 Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames

Authors: M. Zhang, D. Eastlake 3rd, R. Perlman, H. Zhai, D. Liu.

Date: May 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8397

TRILL (Transparent Interconnection of Lots of Links) routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus.

RFC 8398 Internationalized Email Addresses in X.509 Certificates

Authors: A. Melnikov, Ed., W. Chuang, Ed..

Date: May 2018

Formats: txt html json

Updates: RFC 5280

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8398

This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer AlternativeName extension that allows a certificate subject to be associated with an internationalized email address.
This document updates RFC 5280.

RFC 8399 Internationalization Updates to RFC 5280

Authors: R. Housley.

Date: May 2018

Formats: txt html json

Obsoleted by: RFC 9549

Updates: RFC 5280

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8399

The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates.

RFC 8400 Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection

Authors: H. Chen, A. Liu, T. Saad, F. Xu, L. Huang.

Date: June 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8400

This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP)Traffic Engineered (TE) Label Switched Path (LSP).

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 8403 A Scalable and Topology-Aware MPLS Data-Plane Monitoring System

Authors: R. Geib, Ed., C. Filsfils, C. Pignataro, Ed., N. Kumar.

Date: July 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8403

This document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations,Administration, and Maintenance (OAM) measurements while enabling newOAM features.

RFC 8404 Effects of Pervasive Encryption on Operators

Authors: K. Moriarty, Ed., A. Morton, Ed..

Date: July 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8404

Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developingIETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks.

RFC 8405 Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs

Authors: B. Decraene, S. Litkowski, H. Gredler, A. Lindem, P. Francois, C. Bowers.

Date: June 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8405

This document defines a standard algorithm to temporarily postpone or"back off" link-state IGP Shortest Path First (SPF) computations.This reduces the computational load and churn on IGP nodes when multiple temporally close network events trigger multiple SPF computations.
Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple temporally closeIGP events.

RFC 8406 Taxonomy of Coding Techniques for Efficient Network Communications

Authors: B. Adamson, C. Adjih, J. Bilbao, V. Firoiu, F. Fitzek, S. Ghanem, E. Lochin, A. Masucci, M-J. Montpetit, M. Pedersen, G. Peralta, V. Roca, Ed., P. Saxena, S. Sivakumar.

Date: June 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8406

This document summarizes recommended terminology for Network Coding concepts and constructs. It provides a comprehensive set of terms in order to avoid ambiguities in future IRTF and IETF documents onNetwork Coding. This document is the product of the Coding forEfficient Network Communications Research Group (NWCRG), and it is in line with the terminology used by the RFCs produced by the ReliableMulticast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups.

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 8409 The Entity Category Security Assertion Markup Language (SAML) Attribute Types

Authors: I. Young, Ed., L. Johansson, S. Cantor.

Date: August 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8409

This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories.
This document is a product of the working group process of theResearch and Education FEDerations (REFEDS) group.

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 8411 IANA Registration for the Cryptographic Algorithm Object Identifier Range

Authors: J. Schaad, R. Andrews.

Date: August 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8411

When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.

RFC 8412 Software Inventory Message and Attributes (SWIMA) for PA-TNC

Authors: C. Schmidt, D. Haynes, C. Coffin, D. Waltermire, J. Fitzgerald-McKay.

Date: July 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8412

This document extends "PA-TNC: A Posture Attribute (PA) ProtocolCompatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA):Overview and Requirements" (RFC 5209).

RFC 8413 Framework for Scheduled Use of Resources

Authors: Y. Zhuang, Q. Wu, H. Chen, A. Farrel.

Date: July 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8413

Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.

RFC 8414 OAuth 2.0 Authorization Server Metadata

Authors: M. Jones, N. Sakimura, J. Bradley.

Date: June 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8414

This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with anOAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.

RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Authors: T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, T. Winters.

Date: November 2018

Formats: txt html json

Obsoletes: RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, RFC 7550

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8415

This document describes the Dynamic Host Configuration Protocol forIPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes.Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).
This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083,RFC 7283, and RFC 7550.

RFC 8416 Simplified Local Internet Number Resource Management with the RPKI (SLURM)

Authors: D. Ma, D. Mandelberg, T. Bruijnzeels.

Date: August 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8416

The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of InternetNumber Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers(ISPs), can use the RPKI to validate BGP route origin assertions.ISPs can also use the RPKI to validate the path of a BGP route.However, ISPs may want to establish a local view of exceptions to theRPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding globalRPKI repository data as needed.

RFC 8417 Security Event Token (SET)

Authors: P. Hunt, Ed., M. Jones, W. Denniss, M. Ansari.

Date: July 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8417

This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSONWeb Token (JWT), which can be optionally signed and/or encrypted.SETs can be distributed via protocols such as HTTP.

RFC 8418 Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)

Authors: R. Housley.

Date: August 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8418

This document describes the conventions for using the Elliptic CurveDiffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).

RFC 8419 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)

Authors: R. Housley.

Date: August 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8419

This document specifies the conventions for using the Edwards-curveDigital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS.

RFC 8420 Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: Y. Nir.

Date: August 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8420

This document describes the use of the Edwards-curve DigitalSignature Algorithm (EdDSA) in the Internet Key Exchange ProtocolVersion 2 (IKEv2).

RFC 8421 Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)

Authors: P. Martinsen, T. Reddy, P. Patil.

Date: July 2018

Formats: txt html json

Also: BCP 0217

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8421

This document provides guidelines on how to make InteractiveConnectivity Establishment (ICE) conclude faster in multihomed andIPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backward compatible with the original ICE specification (see RFC 5245).

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 8423 Reclassification of Suite B Documents to Historic Status

Authors: R. Housley, L. Zieglar.

Date: July 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8423

This document reclassifies the RFCs related to the United StatesNational Security Agency (NSA) Suite B cryptographic algorithms asHistoric, and it discusses the reasons for doing so. This document moves seven Informational RFCs to Historic status: RFCs 5759, 6239,6318, 6379, 6380, 6403, and 6460. In addition, it moves three obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and5430.

RFC 8424 Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection

Authors: H. Chen, Ed., R. Torvi, Ed..

Date: August 2018

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8424

This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) TrafficEngineered (TE) Label Switched Path (LSP). It extends the FastReroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental.

RFC 8425 IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags

Authors: O. Troan.

Date: July 2018

Formats: txt html json

Updates: RFC 4861

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8425

The Prefix Information Option (PIO) in the IPv6 Neighbor DiscoveryRouter Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved(Reserved1). RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861. The purpose of this document is to create an IANA registry for the PIO flags. This document updates RFC 4861.

RFC 8426 Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence

Authors: H. Sitaraman, Ed., V. Beeram, I. Minei, S. Sivabalan.

Date: July 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8426

Operators are looking to introduce services over Segment Routing (SR)Label Switched Paths (LSPs) in networks running Resource ReservationProtocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SRLSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network.Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE.

RFC 8427 Representing DNS Messages in JSON

Authors: P. Hoffman.

Date: July 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8427

Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios.

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 8429 Deprecate Triple-DES (3DES) and RC4 in Kerberos

Authors: B. Kaduk, M. Short.

Date: October 2018

Formats: txt html json

Updates: RFC 3961, RFC 4120

Also: BCP 0218

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8429

The triple-DES (3DES) and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos. Accordingly, RFC 4757 has been moved toHistoric status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types.

RFC 8430 RIB Information Model

Authors: N. Bahadur, Ed., S. Kini, Ed., J. Medved.

Date: September 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8430

Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using aRouting Information Base (RIB). Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding. This document specifies an information model for the RIB to enable defining a standardized data model. The IETF's I2RS WG used this document to design the I2RS RIB data model. This document is being published to record the higher- level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts.

RFC 8431 A YANG Data Model for the Routing Information Base (RIB)

Authors: L. Wang, M. Chen, A. Dass, H. Ananthakrishnan, S. Kini, N. Bahadur.

Date: September 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8431

This document defines a YANG data model for the Routing InformationBase (RIB) that aligns with the Interface to the Routing System(I2RS) RIB information model.

RFC 8432 A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters

Authors: J. Ahlberg, Ed., M. Ye, Ed., X. Li, LM. Contreras, CJ. Bernardos.

Date: October 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8432

The unification of control and management of microwave radio link interfaces is a precondition for seamless multi-layer networking and automated network provisioning and operation.
This document describes the required characteristics and use cases for control and management of radio link interface parameters using aYANG data model.
The purpose is to create a framework to identify the necessary information elements and define a YANG data model for control and management of the radio link interfaces in a microwave node. Some parts of the resulting model may be generic and could also be used by other technologies, e.g., Ethernet technology.

RFC 8433 A Simpler Method for Resolving Alert-Info URNs

Authors: D. Worley.

Date: August 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8433

The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone(user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call.
RFC 7462 describes a non-normative algorithm for signal selection.This document describes a more efficient alternative algorithm: a user agent's designer can, based on the user agent's signals and their meanings, construct a finite state machine (FSM) to process theURNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace.

RFC 8434 Requirements for Parallel NFS (pNFS) Layout Types

Authors: T. Haynes.

Date: August 2018

Formats: txt html json

Updates: RFC 5661

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8434

This document defines the requirements that individual Parallel NFS(pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661. In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout. The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types. In this regard, this document updates RFC 5661.

RFC 8435 Parallel NFS (pNFS) Flexible File Layout

Authors: B. Halevy, T. Haynes.

Date: August 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8435

Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Client-side mirroring is also added to provide replication of files.

RFC 8436 Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry

Authors: G. Fairhurst.

Date: August 2018

Formats: txt json html

Updates: RFC 2474

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8436

The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. TheInternet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values.
This update to RFC 2474 changes the IANA registration policy for Pool3 of the registry (i.e., DSCP values of the form xxxx01) to StandardsAction, i.e., values are assigned through a Standards Track or BestCurrent Practice RFC. The update also removes permission for experimental and local use of the codepoints that form Pool 3 of theDSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes.

RFC 8437 IMAP UNAUTHENTICATE Extension for Connection Reuse

Authors: C. Newman.

Date: August 2018

Formats: txt json html

Updates: RFC 3501

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8437

This specification extends the Internet Message Access Protocol(IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities.

RFC 8438 IMAP Extension for STATUS=SIZE

Authors: S. Bosch.

Date: August 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8438

This document adds a new capability called "STATUS=SIZE" to theInternet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox.

RFC 8439 ChaCha20 and Poly1305 for IETF Protocols

Authors: Y. Nir, A. Langley.

Date: June 2018

Formats: txt html json

Obsoletes: RFC 7539

Status: INFORMATIONAL

DOI: 10.17487/RFC 8439

This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data(AEAD) algorithm.
RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the SecurityConsiderations section.

RFC 8440 IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST

Authors: K. Murchison, B. Gondwana.

Date: August 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8440

This document defines an extension to the Internet Message AccessProtocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command.

RFC 8441 Bootstrapping WebSockets with HTTP/2

Authors: P. McManus.

Date: September 2018

Formats: txt json html

Updates: RFC 6455

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8441

This document defines a mechanism for running the WebSocket Protocol(RFC 6455) over a single stream of an HTTP/2 connection.

RFC 8442 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2

Authors: J. Mattsson, D. Migault.

Date: September 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8442

This document defines several new cipher suites for version 1.2 of the Transport Layer Security (TLS) protocol and version 1.2 of theDatagram Transport Layer Security (DTLS) protocol. These cipher suites are based on the Ephemeral Elliptic Curve Diffie-Hellman withPre-Shared Key (ECDHE_PSK) key exchange together with theAuthenticated Encryption with Associated Data (AEAD) algorithmsAES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM andAES-CCM provide encryption and integrity protection.

RFC 8443 Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization

Authors: R. Singh, M. Dolly, S. Das, A. Nguyen.

Date: August 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8443

This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization.

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 8446 The Transport Layer Security (TLS) Protocol Version 1.3

Authors: E. Rescorla.

Date: August 2018

Formats: txt html json

Obsoletes: RFC 5077, RFC 5246, RFC 6961

Updates: RFC 5705, RFC 6066

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8446

This document specifies version 1.3 of the Transport Layer Security(TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077,5246, and 6961. This document also specifies new requirements forTLS 1.2 implementations.

RFC 8447 IANA Registry Updates for TLS and DTLS

Authors: J. Salowey, S. Turner.

Date: August 2018

Formats: txt html json

Updates: RFC 3749, RFC 4680, RFC 5077, RFC 5246, RFC 5705, RFC 5878, RFC 6520, RFC 7301

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8447

This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.
This document updates the following RFCs: 3749, 5077, 4680, 5246,5705, 5878, 6520, and 7301.

RFC 8448 Example Handshake Traces for TLS 1.3

Authors: M. Thomson.

Date: January 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8448

This document includes examples of TLS 1.3 handshakes. Private keys and inputs are provided so that these handshakes might be reproduced.Intermediate values, including secrets, traffic keys, and IVs, are shown so that implementations might be checked incrementally against these values.

RFC 8449 Record Size Limit Extension for TLS

Authors: M. Thomson.

Date: August 2018

Formats: txt json html

Updates: RFC 6066

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8449

An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.
This replaces the maximum fragment length extension defined inRFC 6066.

RFC 8450 RTP Payload Format for VC-2 High Quality (HQ) Profile

Authors: J. Weaver.

Date: October 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8450

This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television EngineersStandard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.
The HQ profile of VC-2 is intended for low-latency video compression(with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1).

RFC 8451 Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API

Authors: V. Singh, R. Huang, R. Even, D. Romascanu, L. Deng.

Date: September 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8451

This document describes monitoring features related to media streams in Web real-time communication (WebRTC). It provides a list of RTPControl Protocol (RTCP) Sender Report (SR), Receiver Report (RR), andExtended Report (XR) metrics, which may need to be supported by RTP implementations in some diverse environments. It lists a set of identifiers for the WebRTC's statistics API. These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows.

RFC 8452 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption

Authors: S. Gueron, A. Langley, Y. Lindell.

Date: April 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8452

This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated.
This document is the product of the Crypto Forum Research Group.

RFC 8453 Framework for Abstraction and Control of TE Networks (ACTN)

Authors: D. Ceccarelli, Ed., Y. Lee, Ed..

Date: August 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8453

Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.
Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.
This document provides a framework for Abstraction and Control of TENetworks (ACTN) to support virtual network services and connectivity services.

RFC 8454 Information Model for Abstraction and Control of TE Networks (ACTN)

Authors: Y. Lee, S. Belotti, D. Dhody, D. Ceccarelli, B. Yoon.

Date: September 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8454

This document provides an information model for Abstraction andControl of TE Networks (ACTN).

RFC 8455 Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance

Authors: V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks.

Date: October 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8455

This document defines terminology for benchmarking a Software-DefinedNetworking (SDN) controller's control-plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers. The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services.

RFC 8456 Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance

Authors: V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks.

Date: October 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8456

This document defines methodologies for benchmarking the control- plane performance of Software-Defined Networking (SDN) Controllers.The SDN Controller is a core component in the SDN architecture that controls the behavior of the network. SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. This document provides a method for measuring the performance of all controller implementations.

RFC 8457 IMAP "$Important" Keyword and "\Important" Special-Use Attribute

Authors: B. Leiba, Ed..

Date: September 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8457

RFC 6154 created an IMAP special-use LIST extension and defined an initial set of attributes. This document defines a new attribute,"\Important", and establishes a new IANA registry for IMAP folder attributes, which include the attributes defined in RFCs 5258, 3501, and 6154. This document also defines a new IMAP keyword,"$Important", and registers it in the registry defined in RFC 5788.

RFC 8458 Using National Bibliography Numbers as Uniform Resource Names

Authors: J. Hakala.

Date: October 2018

Formats: txt json html

Obsoletes: RFC 3188

Status: INFORMATIONAL

DOI: 10.17487/RFC 8458

National Bibliography Numbers (NBNs) are used by national libraries and other organizations in order to identify resources in their collections. NBNs are usually applied to resources that are not catered for by established (standard) identifier systems such asInternational Standard Book Number (ISBN).
A Uniform Resource Name (URN) namespace for NBNs was established in2001 in RFC 3188. Since then, a number of European national libraries have implemented URN:NBN-based systems.
This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration(version 4) compliant to RFC 8141 is included.

RFC 8459 Hierarchical Service Function Chaining (hSFC)

Authors: D. Dolson, S. Homma, D. Lopez, M. Boucadair.

Date: September 2018

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8459

Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration.
The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators.

RFC 8460 SMTP TLS Reporting

Authors: D. Margolis, A. Brotman, B. Ramakrishnan, J. Jones, M. Risher.

Date: September 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8460

A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS-Based Authentication of Named Entities (DANE) TLSA, and MTA StrictTransport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.

RFC 8461 SMTP MTA Strict Transport Security (MTA-STS)

Authors: D. Margolis, M. Risher, B. Ramakrishnan, A. Brotman, J. Jones.

Date: September 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8461

SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receiveTransport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

RFC 8462 Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)

Authors: N. Rooney, S. Dawkins, Ed..

Date: October 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8462

The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World(MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members, and participants from various organizations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators.
The group discussed Internet encryption trends and deployment issues identified within the IETF and the privacy needs of users that should be adhered to. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed; in addition, issues experienced when using current transport-layer protocols were also discussed. Content providers and ContentDelivery Networks (CDNs) gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation were discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for-privacy technologies back to regulators.
A group of suggested solutions were devised, which will be discussed in various IETF groups moving forward.

RFC 8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)

Authors: J. Levine.

Date: September 2018

Formats: txt html json

Updates: RFC 6376

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8463

This document adds a new signing algorithm, Ed25519-SHA256, to"DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm.

RFC 8464 A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)

Authors: R. Atarius.

Date: September 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8464

This document defines a Uniform Resource Name (URN) namespace for theThird Generation Partnership Project 2 (3GPP2) and a NamespaceSpecific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the 3GPP2 to uniquely identify each individual mobile equipment(e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement.

RFC 8465 Using the Mobile Equipment Identity (MEID) URN as an Instance ID

Authors: R. Atarius, Ed..

Date: September 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8465

This document specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the MobileEquipment Identity (MEID) can be used as an Instance ID. The purpose of this Instance ID is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance"Contact header field parameter for outbound behavior.

RFC 8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery

Authors: B. Wen, G. Fioccola, Ed., C. Xie, L. Jalil.

Date: October 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8466

This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.
The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipointVirtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border GatewayProtocol (BGP) as described in RFCs 4761 and 6624.
The YANG data model defined in this document conforms to the NetworkManagement Datastore Architecture defined in RFC 8342.

RFC 8467 Padding Policies for Extension Mechanisms for DNS (EDNS(0))

Authors: A. Mayrhofer.

Date: October 2018

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8467

RFC 7830 specifies the "Padding" option for Extension Mechanisms forDNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.

RFC 8468 IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework

Authors: A. Morton, J. Fabini, N. Elkins, M. Ackermann, V. Hegde.

Date: November 2018

Formats: txt json html

Updates: RFC 2330

Status: INFORMATIONAL

DOI: 10.17487/RFC 8468

This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework.Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks(6LoWPAN) are considered and excluded from the standard-formed packet evaluation.

RFC 8469 Recommendation to Use the Ethernet Control Word

Authors: S. Bryant, A. Malis, I. Bagdonas.

Date: November 2018

Formats: txt json html

Updates: RFC 4448

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8469

The pseudowire (PW) encapsulation of Ethernet, as defined inRFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR).This may lead to the selection of the wrong equal-cost multipath(ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet Media Access Control (MAC) addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.
This document updates RFC 4448.

RFC 8470 Using Early Data in HTTP

Authors: M. Thomson, M. Nottingham, W. Tarreau.

Date: September 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8470

Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.

RFC 8471 The Token Binding Protocol Version 1.0

Authors: A. Popov, Ed., M. Nystroem, D. Balfanz, J. Hodges.

Date: October 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8471

This document specifies version 1.0 of the Token Binding protocol.The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, theToken Binding identifiers are only conveyed over TLS and can be reset by the user at any time.

RFC 8472 Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation

Authors: A. Popov, Ed., M. Nystroem, D. Balfanz.

Date: October 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8472

This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters. Negotiation of Token Binding in TLS 1.3 and later versions is beyond the scope of this document.

RFC 8473 Token Binding over HTTP

Authors: A. Popov, M. Nystroem, D. Balfanz, Ed., N. Harper, J. Hodges.

Date: October 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8473

This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.
We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens that it issues to a client -- and that the client subsequently returns to the server -- to the TLS connection between the client and the server. Such bound security tokens are protected from misuse, since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.
Federated Token Bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.
This document is a companion document to "The Token Binding ProtocolVersion 1.0" (RFC 8471).

RFC 8474 IMAP Extension for Object Identifiers

Authors: B. Gondwana, Ed..

Date: September 2018

Formats: txt json html

Updates: RFC 3501

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8474

This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server.

RFC 8475 Using Conditional Router Advertisements for Enterprise Multihoming

Authors: J. Linkova, M. Stucchi.

Date: October 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8475

This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation:Requirements and Solution" could be applied in those scenarios. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The aforementioned document proposes a solution to this problem by introducing a new routing functionality(Source Address Dependent Routing) to solve the uplink selection issue. It also proposes using Router Advertisements to influence the host source address selection. It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases. In particular, the focus of this document is on scenarios in which an enterprise network has twoInternet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028.

RFC 8476 Signaling Maximum SID Depth (MSD) Using OSPF

Authors: J. Tantsura, U. Chunduri, S. Aldrin, P. Psenak.

Date: December 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8476

This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths(MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3.

RFC 8477 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016

Authors: J. Jimenez, H. Tschofenig, D. Thaler.

Date: October 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8477

This document provides a summary of the "Workshop on Internet ofThings (IoT) Semantic Interoperability (IOTSI)", which took place inSanta Clara, California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the workshop. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 8478 Zstandard Compression and the application/zstd Media Type

Authors: Y. Collet, M. Kucherawy, Ed..

Date: October 2018

Formats: txt json html

Obsoleted by: RFC 8878

Status: INFORMATIONAL

DOI: 10.17487/RFC 8478

Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet MailExtensions (MIME).
Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.

RFC 8479 Storing Validation Parameters in PKCS#8

Authors: N. Mavrogiannopoulos.

Date: September 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8479

This memo describes a method of storing parameters needed for private-key validation in the Private-Key Information SyntaxSpecification as defined in PKCS#8 format (RFC 5208). It is equally applicable to the alternative implementation of the Private-KeyInformation Syntax Specification as defined in RFC 5958.
The approach described in this document encodes the parameters under a private enterprise extension and does not form part of a formal standard.

RFC 8480 6TiSCH Operation Sublayer (6top) Protocol (6P)

Authors: Q. Wang, Ed., X. Vilajosana, T. Watteyne.

Date: November 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8480

This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e"(6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.

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 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY

Authors: J. Abley, O. Gudmundsson, M. Majkowski, E. Hunt.

Date: January 2019

Formats: txt html json

Updates: RFC 1034, RFC 1035

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8482

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.
The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.
This document updates RFCs 1034 and 1035.

RFC 8483 Yeti DNS Testbed

Authors: L. Song, Ed., D. Liu, P. Vixie, A. Kato, S. Kerr.

Date: October 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8483

Yeti DNS is an experimental, non-production root server testbed that provides an environment where technical and operational experiments can safely be performed without risk to production root server infrastructure. This document aims solely to document the technical and operational experience of deploying a system that is similar to but different from the Root Server system (on which the Internet'sDomain Name System is designed and built).

RFC 8484 DNS Queries over HTTPS (DoH)

Authors: P. Hoffman, P. McManus.

Date: October 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8484

This document defines a protocol for sending DNS queries and gettingDNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.

RFC 8485 Vectors of Trust

Authors: J. Richer, Ed., L. Johansson.

Date: October 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8485

This document defines a mechanism for describing and signaling several aspects of a digital identity transaction and its participants. These aspects are used to determine the amount of trust to be placed in that transaction.

RFC 8486 Ambisonics in an Ogg Opus Container

Authors: J. Skoglund, M. Graczyk.

Date: October 2018

Formats: txt html json

Updates: RFC 7845

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8486

This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families.

RFC 8487 Mtrace Version 2: Traceroute Facility for IP Multicast

Authors: H. Asaeda, K. Meyer, W. Lee, Ed..

Date: October 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8487

This document describes the IP multicast traceroute facility, namedMtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply.

RFC 8488 RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation

Authors: O. Muravskiy, T. Bruijnzeels.

Date: December 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8488

This document describes an approach to validating the content of theResource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both.

RFC 8489 Session Traversal Utilities for NAT (STUN)

Authors: M. Petit-Huguenin, G. Salgueiro, J. Rosenberg, D. Wing, R. Mahy, P. Matthews.

Date: February 2020

Formats: txt json html

Obsoletes: RFC 5389

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8489

Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with 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 document obsoletes RFC 5389.

RFC 8490 DNS Stateful Operations

Authors: R. Bellis, S. Cheshire, J. Dickinson, S. Dickinson, T. Lemon, T. Pusateri.

Date: March 2019

Formats: txt json html

Updates: RFC 1035, RFC 7766

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8490

This document defines a new DNS OPCODE for DNS Stateful Operations(DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a newDNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.

RFC 8491 Signaling Maximum SID Depth (MSD) Using IS-IS

Authors: J. Tantsura, U. Chunduri, S. Aldrin, L. Ginsberg.

Date: November 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8491

This document defines a way for an Intermediate System toIntermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type ofMSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.

RFC 8492 Secure Password Ciphersuites for Transport Layer Security (TLS)

Authors: D. Harkins, Ed..

Date: February 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8492

This memo defines several new ciphersuites for the Transport LayerSecurity (TLS) protocol to support certificateless, secure authentication using only a simple, low-entropy password. The exchange is called "TLS-PWD". The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to offline dictionary attacks.

RFC 8493 The BagIt File Packaging Format (V1.0)

Authors: J. Kunze, J. Littman, E. Madden, J. Scancella, C. Adams.

Date: October 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8493

This document describes BagIt, a set of hierarchical file layout conventions for storage and transfer of arbitrary digital content. A"bag" has just enough structure to enclose descriptive metadata"tags" and a file "payload" but does not require knowledge of the payload's internal semantics. This BagIt format is suitable for reliable storage and transfer.

RFC 8494 Multicast Email (MULE) over Allied Communications Publication (ACP) 142

Authors: D. Wilson, A. Melnikov, Ed..

Date: November 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8494

Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (MulticastEmail), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP142). MULE enables transfer between Message Transfer Agents (MTAs).It doesn't provide a service similar to SMTP Submission (as described in RFC 6409).
This document explains how MULE can be used in conjunction with SMTP(RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism.
This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics.

RFC 8495 Allocation Token Extension for the Extensible Provisioning Protocol (EPP)

Authors: J. Gould, K. Feher.

Date: November 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8495

This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in "query" and"transform" commands. The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer".

RFC 8496 P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP)

Authors: D. York, T. Asveren.

Date: October 2018

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8496

This text documents the current usage of P-Charge-Info, an existingSession Initiation Protocol (SIP) private header field (P-Header) used to convey billing information about the party to be charged.This P-Header is currently used in production by several equipment vendors and carriers and has been in use since at least 2007. This document details the registration of this header field with IANA.

RFC 8497 Marking SIP Messages to Be Logged

Authors: P. Dawes, C. Arunachalam.

Date: November 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8497

SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent(UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.
This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling.Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminatingSIP user agents, even if a session originates and terminates in different networks.

RFC 8498 A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)

Authors: M. Mohali.

Date: February 2019

Formats: txt json html

Updates: RFC 5502

Status: INFORMATIONAL

DOI: 10.17487/RFC 8498

The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP MultimediaSubsystem) in order to convey the identity of the served user, his/ her registration state, and the session case that applies to that particular communication session and application invocation. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. This document updates RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user. This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks.

RFC 8499 DNS Terminology

Authors: P. Hoffman, A. Sullivan, K. Fujiwara.

Date: January 2019

Formats: txt json html

Obsoletes: RFC 7719

Obsoleted by: RFC 9499

Updates: RFC 2308

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8499

The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in theDNS in a single document.
This document obsoletes RFC 7719 and updates RFC 2308.

RFC 8500 IS-IS Routing with Reverse Metric

Authors: N. Shen, S. Amante, M. Abrahamsson.

Date: February 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8500

This document describes a mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to-point or multi-access LAN interface during network maintenance or other operational events. This is accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric, i.e., the metric towards the signaling IS-IS router.

RFC 8501 Reverse DNS in IPv6 for Internet Service Providers

Authors: L. Howard.

Date: November 2018

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8501

In IPv4, Internet Service Providers (ISPs) commonly provideIN-ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone.

RFC 8502 L2L3 VPN Multicast MIB

Authors: Z. Zhang, H. Tsunoda.

Date: December 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8502

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 two MIB modules that will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer3 Virtual Private Networks that support multicast.

RFC 8503 BGP/MPLS Layer 3 VPN Multicast Management Information Base

Authors: H. Tsunoda.

Date: December 2018

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8503

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 to configure and/or monitor Multicast communication over IP Virtual Private Networks(VPNs) supported by the Multiprotocol Label Switching/Border GatewayProtocol (MPLS/BGP) on a Provider Edge (PE) router.

RFC 8504 IPv6 Node Requirements

Authors: T. Chown, J. Loughney, T. Winters.

Date: January 2019

Formats: txt json html

Obsoletes: RFC 6434

Also: BCP 0220

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8504

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
This document obsoletes RFC 6434, and in turn RFC 4294.

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 8506 Diameter Credit-Control Application

Authors: L. Bertz, Ed., D. Dolson, Ed., Y. Lifshitz, Ed..

Date: March 2019

Formats: txt html json

Obsoletes: RFC 4006

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8506

This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The Diameter Credit-Control application as defined in this document obsoletes RFC 4006, and it must be supported by all new Diameter Credit-Control application implementations.

RFC 8507 Simple Internet Protocol (SIP) Specification

Authors: S. Deering, R. Hinden, Ed..

Date: December 2018

Formats: txt html json

Status: HISTORIC

DOI: 10.17487/RFC 8507

This document is published for the historical record. The SimpleInternet Protocol was the basis for one of the candidates for theIETF's Next Generation (IPng) work that became IPv6.
The publication date of the original Internet-Draft was November 10,1992. It is presented here substantially unchanged and is neither a complete document nor intended to be implementable.
The paragraph that follows is the Abstract from the original draft.
This document specifies a new version of IP called SIP, the SimpleInternet Protocol. It also describes the changes needed to ICMP,IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast.

RFC 8508 IMAP REPLACE Extension

Authors: S. Brandt.

Date: January 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8508

This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them.

RFC 8509 A Root Key Trust Anchor Sentinel for DNSSEC

Authors: G. Huston, J. Damas, W. Kumari.

Date: December 2018

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8509

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 a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key.

RFC 8510 OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement

Authors: P. Psenak, Ed., K. Talaulikar, W. Henderickx, P. Pillay-Esnault.

Date: January 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8510

Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. In some cases, it is useful to know the assigned Interface ID on the remote side of the adjacency(Remote Interface ID).
This document describes the extensions to OSPF link-local signaling(LLS) to advertise the Local Interface ID.

RFC 8511 TCP Alternative Backoff with ECN (ABE)

Authors: N. Khademi, M. Welzl, G. Armitage, G. Fairhurst.

Date: December 2018

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8511

Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced(CE) Explicit Congestion Notification (ECN) mark indicates that anAQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss.Therefore, this specification defines an experimental change to theTCP reaction specified in RFC 3168, as permitted by RFC 8311.

RFC 8512 A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)

Authors: M. Boucadair, Ed., S. Sivakumar, C. Jacquenet, S. Vinapamula, Q. Wu.

Date: January 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8512

This document defines a YANG module for the Network AddressTranslation (NAT) function.
Network Address Translation from IPv4 to IPv4 (NAT44), NetworkAddress and Protocol Translation from IPv6 Clients to IPv4 Servers(NAT64), customer-side translator (CLAT), Stateless IP/ICMPTranslation (SIIT), Explicit Address Mappings (EAM) for SIIT,IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT are covered in this document.

RFC 8513 A YANG Data Model for Dual-Stack Lite (DS-Lite)

Authors: M. Boucadair, C. Jacquenet, S. Sivakumar.

Date: January 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8513

This document defines a YANG module for the Dual-Stack Lite (DS-Lite)Address Family Transition Router (AFTR) and Basic Bridging BroadBand(B4) elements.

RFC 8514 Internet Message Access Protocol (IMAP) - SAVEDATE Extension

Authors: S. Bosch.

Date: January 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8514

This document adds a new capability called "SAVEDATE" to the InternetMessage Access Protocol (IMAP). It defines a new IMAP message attribute called "save date" that, unlike the existing "internal date" attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends theFETCH command with the means to retrieve the save date attribute and extends the SEARCH command to allow using the save date attribute in searching criteria.

RFC 8515 URN Namespace for ETSI Documents

Authors: M. Jethanandani, M.A. Reina Ortega.

Date: February 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8515

This document describes the Namespace Identifier (NID) "etsi" forUniform Resource Names (URNs) used to identify resources published by the European Telecommunications Standards Institute(http://etsi.org). ETSI specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the ETSI ProtocolNaming and Numbering Service (PNNS).

RFC 8516 "Too Many Requests" Response Code for the Constrained Application Protocol

Authors: A. Keranen.

Date: January 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8516

A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP response code for a server to indicate that a client should reduce the rate of requests.

RFC 8517 An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective

Authors: D. Dolson, Ed., J. Snellman, M. Boucadair, Ed., C. Jacquenet.

Date: February 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8517

This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".
RFC 3234 defines a taxonomy of middleboxes and issues in theInternet. Most of those middleboxes utilize or modify application- layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets.

RFC 8518 Selection of Loop-Free Alternates for Multi-Homed Prefixes

Authors: P. Sarkar, Ed., U. Chunduri, Ed., S. Hegde, J. Tantsura, H. Gredler.

Date: March 2019

Formats: txt json html

Updates: RFC 5286

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8518

Deployment experience gained from implementing algorithms to determine Loop-Free Alternates (LFAs) for multi-homed prefixes (MHPs) has revealed some avenues for potential improvement. This document provides explicit inequalities that can be used to evaluate neighbors as potential alternates for MHPs. It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs. This document updates Section 6 of RFC 5286 by expanding some of the routing aspects.

RFC 8519 YANG Data Model for Network Access Control Lists (ACLs)

Authors: M. Jethanandani, S. Agarwal, L. Huang, D. Blair.

Date: March 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8519

This document defines a data model for Access Control Lists (ACLs).An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet.

RFC 8520 Manufacturer Usage Description Specification

Authors: E. Lear, R. Droms, D. Romascanu.

Date: March 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8520

This memo specifies a component-based architecture for ManufacturerUsage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.
This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, aLink Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.

RFC 8521 Registration Data Access Protocol (RDAP) Object Tagging

Authors: S. Hollenbeck, A. Newton.

Date: November 2018

Formats: txt json html

Updates: RFC 7484

Also: BCP 0221

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8521

The Registration Data Access Protocol (RDAP) includes a method that can be used to identify the authoritative server for processing domain name, IP address, and autonomous system number queries. The method does not describe how to identify the authoritative server for processing other RDAP query types, such as entity queries. This limitation exists because the identifiers associated with these query types are typically unstructured. This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers and that makes it possible to identify the authoritative server for additional RDAP queries.

RFC 8522 Looking Glass Command Set

Authors: M. Stubbig.

Date: February 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8522

This document introduces a command set standard to the web-based"Network Looking Glass" software. Its purpose is to provide application programmers uniform access to the Looking Glass service and to analyze a standardized response.
The interface is supposed to provide the same level of information as web-based interfaces, but in a computer-readable format.

RFC 8525 YANG Library

Authors: A. Bierman, M. Bjorklund, J. Schoenwaelder, K. Watsen, R. Wilton.

Date: March 2019

Formats: txt json html

Obsoletes: RFC 7895

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8525

This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management DatastoreArchitecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores.
This document obsoletes RFC 7895.

RFC 8526 NETCONF Extensions to Support the Network Management Datastore Architecture

Authors: M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton.

Date: March 2019

Formats: txt html json

Updates: RFC 6241, RFC 7950

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8526

This document extends the Network Configuration Protocol (NETCONF) defined in RFC 6241 in order to support the Network ManagementDatastore Architecture (NMDA) defined in RFC 8342.
This document updates RFCs 6241 and 7950. The update to RFC 6241 adds new <get-data&rt; and <edit-data&rt; operations and augments existing<lock&rt;, <unlock&rt;, and <validate&rt; operations. The update to RFC 7950 requires the usage of the YANG library (described in RFC 8525) byNETCONF servers implementing the NMDA.

RFC 8527 RESTCONF Extensions to Support the Network Management Datastore Architecture

Authors: M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton.

Date: March 2019

Formats: txt html json

Updates: RFC 8040

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8527

This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of the YANG library (described in RFC 8525) by RESTCONF servers implementing the NMDA.

RFC 8528 YANG Schema Mount

Authors: M. Bjorklund, L. Lhotka.

Date: March 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8528

This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module.

RFC 8529 YANG Data Model for Network Instances

Authors: L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu.

Date: March 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8529

This document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342.

RFC 8530 YANG Model for Logical Network Elements

Authors: L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu.

Date: March 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8530

This document defines a logical network element (LNE) YANG module that is compliant with the Network Management Datastore Architecture(NMDA). This module can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are logical systems or logical routers. The YANG model in this document conforms with NMDA as defined in RFC 8342.

RFC 8531 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols

Authors: D. Kumar, Q. Wu, Z. Wang.

Date: April 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8531

This document presents a base YANG data model for connection-orientedOperations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture.

RFC 8532 Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications

Authors: D. Kumar, Z. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan.

Date: April 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8532

This document presents a base YANG Data model for the management ofOperations, Administration, and Maintenance (OAM) protocols that use connectionless communications. The data model is defined using theYANG data modeling language, as specified in RFC 7950. It provides a technology-independent abstraction of key OAM constructs for OAM protocols that use connectionless communication. The base model presented here can be extended to include technology-specific details.
There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nestedOAM workflows (i.e., performing OAM functions at the same level or different levels through a unified interface) as well as interactiveOAM workflows (i.e., performing OAM functions at the same level through a unified interface).

RFC 8533 A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications

Authors: D. Kumar, M. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan.

Date: April 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8533

This document presents a retrieval method YANG data model for connectionless Operations, Administration, and Maintenance (OAM) protocols. It provides technology-independent RPC operations for OAM protocols that use connectionless communication. The retrieval methods model herein presented can be extended to include technology- specific details. There are two key benefits of this approach:First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at different or the same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same levels through a unified interface).

RFC 8534 Explicit Tracking with Wildcard Routes in Multicast VPN

Authors: A. Dolganow, J. Kotalwar, E. Rosen, Ed., Z. Zhang.

Date: February 2019

Formats: txt json html

Updates: RFC 6514, RFC 6625, RFC 7524, RFC 7582, RFC 7900

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8534

The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide procedures to allow a multicast ingress node to invoke"explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit-tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs6514, 6625, 7524, 7582, and 7900.

RFC 8536 The Time Zone Information Format (TZif)

Authors: A. Olson, P. Eggert, K. Murchison.

Date: February 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8536

This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined.

RFC 8537 Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs)

Authors: R. Gandhi, Ed., H. Shah, J. Whittaker.

Date: February 2019

Formats: txt html json

Updates: RFC 4090, RFC 7551

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8537

Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forwardLSP. This document updates the fast reroute procedures defined inRFC 4090 to support both single-sided and double-sided provisioned associated bidirectional LSPs. This document also updates the procedure for associating two reverse LSPs defined in RFC 7551 to support co-routed bidirectional LSPs. The fast reroute procedures can ensure that, for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after a failure event.

RFC 8538 Notification Message Support for BGP Graceful Restart

Authors: K. Patel, R. Fernando, J. Scudder, J. Haas.

Date: March 2019

Formats: txt json html

Updates: RFC 4724

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8538

The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP messages other than BGPNOTIFICATION messages. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION message or the Hold Time expires. This document also defines a new subcode forBGP Cease NOTIFICATION messages; this new subcode requests a full session restart instead of a Graceful Restart.

RFC 8539 Softwire Provisioning Using DHCPv4 over DHCPv6

Authors: I. Farrer, Q. Sun, Y. Cui, L. Sun.

Date: March 2019

Formats: txt json html

Updates: RFC 7598

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8539

DHCPv4 over DHCPv6 (RFC 7341) is a mechanism for dynamically configuring IPv4 for use as an over-the-top service in an IPv6-only network. Softwires are an example of such a service. For DHCPv4 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios (e.g., RFC 7596 or RFC 7597), the operator needs to know the IPv6 address that the client will use as the source of an IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the client's IPv4 address, and (in some deployments) the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 option to convey IPv6 parameters for establishing the softwire tunnel and a DHCPv4 option (to be used only with DHCP 4o6) to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It is designed to work in conjunction with the IPv4 address allocation process.
"DHCPv6 Options for Configuration of Softwire Address and Port-MappedClients" (RFC 7598) describes a deterministic DHCPv6-based mechanism for provisioning softwires. This document updates RFC 7598, allowingOPTION_S46_BR (90) to be enumerated in the DHCPv6 client's OptionRequest Option (ORO) request and to appear directly within subsequent messages sent by the DHCPv6 server.

RFC 8540 Stream Control Transmission Protocol: Errata and Issues in RFC 4960

Authors: R. Stewart, M. Tuexen, M. Proshin.

Date: February 2019

Formats: txt html json

Obsoleted by: RFC 9260

Status: INFORMATIONAL

DOI: 10.17487/RFC 8540

This document is a compilation of issues found since the publication of RFC 4960 in September 2007, based on experience with implementing, testing, and using the Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC4960 and is organized in a time-ordered way. The issues are listed in the order in which they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the deltas, a description of each problem and the details of the solution for each are also provided.

RFC 8541 Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops

Authors: S. Litkowski, B. Decraene, M. Horneffer.

Date: March 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8541

A micro-loop is a packet-forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet-forwarding paradigm.
This document analyzes the impact of using different link state IGP implementations in a single network with respect to micro-loops. The analysis is focused on the Shortest Path First (SPF) delay algorithm but also mentions the impact of SPF trigger strategies.

RFC 8542 A YANG Data Model for Fabric Topology in Data-Center Networks

Authors: Y. Zhuang, D. Shi, R. Gu, H. Ananthakrishnan.

Date: March 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8542

This document defines a YANG data model for fabric topology in data- center networks and represents one possible view of the data-center fabric. This document focuses on the data model only and does not endorse any kind of network design that could be based on the abovementioned model.

RFC 8543 Extensible Provisioning Protocol (EPP) Organization Mapping

Authors: L. Zhou, N. Kong, J. Yao, J. Gould, G. Zhou.

Date: March 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8543

This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of organization objects stored in a shared central repository.

RFC 8544 Organization Extension for the Extensible Provisioning Protocol (EPP)

Authors: L. Zhou, N. Kong, J. Wei, J. Yao, J. Gould.

Date: April 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8544

This document describes an extension to Extensible ProvisioningProtocol (EPP) object mappings that is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects.

RFC 8545 Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)

Authors: A. Morton, Ed., G. Mirsky, Ed..

Date: March 2019

Formats: txt html json

Updates: RFC 4656, RFC 5357

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8545

This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of theseStandards Track protocol names for the industry.
This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry.

RFC 8546 The Wire Image of a Network Protocol

Authors: B. Trammell, M. Kuehlewind.

Date: April 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8546

This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image.

RFC 8547 TCP-ENO: Encryption Negotiation Option

Authors: A. Bittau, D. Giffin, M. Handley, D. Mazieres, E. Smith.

Date: May 2019

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8547

Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors.First, some legacy protocols lack a signaling mechanism (such as aSTARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption.

RFC 8548 Cryptographic Protection of TCP Streams (tcpcrypt)

Authors: A. Bittau, D. Giffin, M. Handley, D. Mazieres, Q. Slack, E. Smith.

Date: May 2019

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8548

This document specifies "tcpcrypt", a TCP encryption protocol designed for use in conjunction with the TCP Encryption NegotiationOption (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header. The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable.Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data can be transmitted. However, the extra latency can be avoided between two hosts that have recently established a previous tcpcrypt connection.

RFC 8549 Export of BGP Community Information in IP Flow Information Export (IPFIX)

Authors: Z. Li, R. Gu, J. Dong.

Date: April 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8549

By introducing new Information Elements (IEs), this document extends the existing BGP-related IEs to enable IP Flow Information Export(IPFIX) to export BGP community information, including the BGPStandard Communities defined in RFC 1997, BGP Extended Communities defined in RFC 4360, and BGP Large Communities defined in RFC 8092.According to the network operator's BGP community planning, network traffic information can then be accumulated and analyzed at the BGP community granularity, which represents the traffic of different kinds of customers, services, or geographical regions. Network traffic information at the BGP community granularity is useful for network traffic analysis and engineering.

RFC 8550 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling

Authors: J. Schaad, B. Ramsdell, S. Turner.

Date: April 2019

Formats: txt html json

Obsoletes: RFC 5750

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8550

This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents.S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing.S/MIME agents validate certificates as described in RFC 5280("Internet X.509 Public Key Infrastructure Certificate andCertificate Revocation List (CRL) Profile"). S/MIME agents must meet the certificate-processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750.

RFC 8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification

Authors: J. Schaad, B. Ramsdell, S. Turner.

Date: April 2019

Formats: txt html json

Obsoletes: RFC 5751

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8551

This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751.

RFC 8552 Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves

Authors: D. Crocker.

Date: March 2019

Formats: txt json html

Also: BCP 0222

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8552

Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the"Underscored and Globally Scoped DNS Node Names" registry with IANA.The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.

RFC 8553 DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names

Authors: D. Crocker.

Date: March 2019

Formats: txt json html

Updates: RFC 2782, RFC 3263, RFC 3529, RFC 3620, RFC 3832, RFC 3887, RFC 3958, RFC 4120, RFC 4227, RFC 4386, RFC 4387, RFC 4976, RFC 5026, RFC 5328, RFC 5389, RFC 5415, RFC 5518, RFC 5555, RFC 5617, RFC 5679, RFC 5766, RFC 5780, RFC 5804, RFC 5864, RFC 5928, RFC 6120, RFC 6186, RFC 6376, RFC 6733, RFC 6763, RFC 7208, RFC 7489, RFC 8145

Also: BCP 0222

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8553

Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace.A registry for these names has now been defined by RFC 8552.However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model.

RFC 8554 Leighton-Micali Hash-Based Signatures

Authors: D. McGrew, M. Curcio, S. Fluhrer.

Date: April 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8554

This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport,Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side- channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them.

RFC 8555 Automatic Certificate Management Environment (ACME)

Authors: R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten.

Date: March 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8555

Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities(CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.

RFC 8556 Multicast VPN Using Bit Index Explicit Replication (BIER)

Authors: E. Rosen, Ed., M. Sivakumar, T. Przygienda, S. Aldrin, A. Dolganow.

Date: April 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8556

The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a"multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network.

RFC 8557 Deterministic Networking Problem Statement

Authors: N. Finn, P. Thubert.

Date: May 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8557

This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties.

RFC 8558 Transport Protocol Path Signals

Authors: T. Hardie, Ed..

Date: April 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8558

This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals.Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.

RFC 8559 Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol

Authors: A. DeKok, J. Korhonen.

Date: April 2019

Formats: txt html json

Updates: RFC 5176, RFC 5580

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8559

RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message(DM) behavior for RADIUS. RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542. This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets.

RFC 8560 Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents

Authors: A. Sajassi, Ed., S. Salam, N. Del Regno, J. Rabadan.

Date: May 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8560

This document specifies mechanisms for backward compatibility ofEthernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN(PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) andProvider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides mechanisms for the seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this document enables service providers to introduce EVPN/PBB-EVPNProvider Edges (PEs) in their brownfield deployments of VPLS/PBB-VPLS networks. This document specifies the control-plane and forwarding behavior needed for the auto-discovery of the following: 1) a VPN instance, 2) multicast and unicast operation, and 3) a Media AccessControl (MAC) mobility operation. This enables seamless integration between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPNPEs.

RFC 8561 A YANG Data Model for Microwave Radio Link

Authors: J. Ahlberg, M. Ye, X. Li, D. Spreafico, M. Vaupotic.

Date: June 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8561

This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typicallyEthernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well.

RFC 8562 Bidirectional Forwarding Detection (BFD) for Multipoint Networks

Authors: D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed..

Date: April 2019

Formats: txt json html

Updates: RFC 5880

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8562

This document describes extensions to the Bidirectional ForwardingDetection (BFD) protocol for its use in multipoint and multicast networks.
This document updates RFC 5880.

RFC 8563 Bidirectional Forwarding Detection (BFD) Multipoint Active Tails

Authors: D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed..

Date: April 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8563

This document describes active tail extensions to the BidirectionalForwarding Detection (BFD) protocol for multipoint networks.

RFC 8564 Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL)

Authors: M. Zhang, S. Pallagatti, V. Govindan.

Date: April 2019

Formats: txt html json

Updates: RFC 7175, RFC 7177

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8564

Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD) is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in Transparent Interconnection ofLots of Links (TRILL). Similar to TRILL point-to-point BFD, BFDControl packets in TRILL P2MP BFD are transmitted using RBridgeChannel messages. This document updates RFCs 7175 and 7177.

RFC 8565 Hypertext Jeopardy Protocol (HTJP/1.0)

Authors: E. Fokschaner.

Date: 1 April 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8565

The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP). Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer. Using HTJP, one connects to a server, sends an answer, and expects a correct question. This document specifies the semantics of HTJP.

RFC 8567 Customer Management DNS Resource Records

Authors: E. Rye, R. Beverly.

Date: 1 April 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8567

Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed CustomerPremises Equipment (CPE). Because customer management is a shared global responsibility, the Domain Name System (DNS) provides an ideal existing infrastructure for maintaining authoritative customer information that must be readily, reliably, and publicly accessible.
This document describes four new DNS resource record types for encoding customer information in the DNS. These records are intended to better facilitate high customer QoE via inter-provider cooperation and management of customer data.

RFC 8568 Network Virtualization Research Challenges

Authors: CJ. Bernardos, A. Rahman, JC. Zuniga, LM. Contreras, P. Aranda, P. Lynch.

Date: April 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8568

This document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges.This document is a product of the Network Function VirtualizationResearch Group (NFVRG).

RFC 8569 Content-Centric Networking (CCNx) Semantics

Authors: M. Mosko, I. Solis, C. Wood.

Date: July 2019

Formats: txt html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8569

This document describes the core concepts of the Content-CentricNetworking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.
The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.
This document is a product of the Information-Centric NetworkingResearch Group (ICNRG). The document received wide review amongICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.

RFC 8570 IS-IS Traffic Engineering (TE) Metric Extensions

Authors: L. Ginsberg, Ed., S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu.

Date: March 2019

Formats: txt html json

Obsoletes: RFC 7810

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8570

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.
This document describes extensions to IS-IS Traffic EngineeringExtensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion.The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.
Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.
This document obsoletes RFC 7810.

RFC 8571 BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions

Authors: L. Ginsberg, Ed., S. Previdi, Q. Wu, J. Tantsura, C. Filsfils.

Date: March 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8571

This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in theIS-IS and OSPF protocols.

RFC 8572 Secure Zero Touch Provisioning (SZTP)

Authors: K. Watsen, I. Farrer, M. Abrahamsson.

Date: April 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8572

This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.

RFC 8573 Message Authentication Code for the Network Time Protocol

Authors: A. Malhotra, S. Goldberg.

Date: June 2019

Formats: txt json html

Updates: RFC 5905

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8573

The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a128-bit key and hashing the result with MD5 to obtain a 128-bit tag.This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement.

RFC 8574 cite-as: A Link Relation to Convey a Preferred URI for Referencing

Authors: H. Van de Sompel, M. Nelson, G. Bilder, J. Kunze, S. Warner.

Date: April 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8574

A web resource is routinely referenced by means of the URI with which it is directly accessed. But cases exist where referencing a resource by means of a different URI is preferred. This specification defines a link relation type that can be used to convey such a preference.

RFC 8575 YANG Data Model for the Precision Time Protocol (PTP)

Authors: Y. Jiang, Ed., X. Liu, J. Xu, R. Cummings, Ed..

Date: May 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8575

This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008. It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks. The YANG module in this document conforms to theNetwork Management Datastore Architecture (NMDA).

RFC 8576 Internet of Things (IoT) Security: State of the Art and Challenges

Authors: O. Garcia-Morchon, S. Kumar, M. Sethi.

Date: April 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8576

The Internet of Things (IoT) concept refers to the usage of standardInternet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the ConstrainedApplication Protocol (CoAP) secured with Datagram Transport LayerSecurity (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing.Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secureIoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.
This document is a product of the IRTF Thing-to-Thing Research Group(T2TRG).

RFC 8577 Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane

Authors: H. Sitaraman, V. Beeram, T. Parikh, T. Saad.

Date: April 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8577

As the scale of MPLS RSVP-TE networks has grown, the number of LabelSwitched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.
However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane.
This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs.This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane.

RFC 8578 Deterministic Networking Use Cases

Authors: E. Grossman, Ed..

Date: May 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8578

This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time- sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.

RFC 8579 Sieve Email Filtering: Delivering to Special-Use Mailboxes

Authors: S. Bosch.

Date: May 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8579

The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute.

RFC 8580 Sieve Extension: File Carbon Copy (FCC)

Authors: K. Murchison, B. Gondwana.

Date: May 2019

Formats: txt html json

Updates: RFC 5230, RFC 5435

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8580

The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox.
This document updates RFCs 5230 and 5435 by adding a new tagged argument to the Vacation and Notify actions, respectively.

RFC 8581 Diameter Agent Overload and the Peer Overload Report

Authors: S. Donovan.

Date: August 2019

Formats: txt html json

Updates: RFC 7683

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8581

This specification documents an extension to the Diameter OverloadIndication Conveyance (DOIC), a base solution for Diameter overload defined in RFC 7683. The extension defines the Peer Overload report type. The initial use case for the peer report is the handling of occurrences of overload of a Diameter Agent.

RFC 8582 Diameter Overload Rate Control

Authors: S. Donovan, Ed., E. Noel.

Date: August 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8582

This specification documents an extension to the Diameter OverloadIndication Conveyance (DOIC) base solution, which is defined in RFC7683. This extension adds a new overload-control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sendsDiameter requests to the DOIC reporting node.

RFC 8583 Diameter Load Information Conveyance

Authors: B. Campbell, S. Donovan, Ed., JJ. Trottin.

Date: August 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8583

RFC 7068 describes requirements for Overload Control in Diameter.This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The base solution defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC)) describes a mechanism meeting most of the requirements but does not currently include the ability to send load information. This document defines a mechanism for the conveying of Diameter load information.

RFC 8584 Framework for Ethernet VPN Designated Forwarder Election Extensibility

Authors: J. Rabadan, Ed., S. Mohanty, Ed., A. Sajassi, J. Drake, K. Nagaraj, S. Sathappan.

Date: April 2019

Formats: txt html json

Updates: RFC 7432

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8584

An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is theProvider Edge (PE) router responsible for sending Broadcast, UnknownUnicast, and Multicast (BUM) traffic to a multihomed Customer Edge(CE) device on a given VLAN on a particular Ethernet Segment (ES).In addition, the ability to influence the DF election result for aVLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite StateMachine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432).

RFC 8585 Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service

Authors: J. Palet Martinez, H. M.-H. Liu, M. Kawashima.

Date: May 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8585

This document specifies the IPv4 service continuity requirements forIPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market.
Specifically, this document extends the basic requirements for IPv6CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only coversIPv4aaS, i.e., transition technologies for delivering IPv4 inIPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local AreaNetworks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet.

RFC 8586 Loop Detection in Content Delivery Networks (CDNs)

Authors: S. Ludin, M. Nottingham, N. Sullivan.

Date: April 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8586

This document defines the CDN-Loop request header field for HTTP.CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks(CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop. The new header field can be used to identify the error and terminate the loop.

RFC 8587 NFS Version 4.0 Trunking Update

Authors: C. Lever, Ed., D. Noveck.

Date: May 2019

Formats: txt json html

Updates: RFC 7530

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8587

In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server file systems. This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530.

RFC 8588 Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)

Authors: C. Wendt, M. Barnes.

Date: May 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8588

This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIPForum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network.

RFC 8589 The 'leaptofrogans' URI Scheme

Authors: A. Tamas, B. Phister, Ed., J-E. Rodriguez.

Date: May 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8589

This document describes the 'leaptofrogans' Uniform ResourceIdentifier (URI) scheme, which enables applications to launch FrogansPlayer on a given Frogans site. Frogans is a medium for publishing content and services on the Internet, defined as a generic software layer on the Internet. Frogans Player is software that enables end users to browse Frogans sites.

RFC 8590 Change Poll Extension for the Extensible Provisioning Protocol (EPP)

Authors: J. Gould, K. Feher.

Date: May 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8590

This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client-sponsored objects that were not initiated by the client through EPP. These operations may include contractual or policy requirements including, but not limited to, regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) orUniform Rapid Suspension (URS) actions, court-directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the postoperation object, and optionally a preoperation object, with the operation metadata of what, when, who, and why.

RFC 8591 SIP-Based Messaging with S/MIME

Authors: B. Campbell, R. Housley.

Date: April 2019

Formats: txt html json

Updates: RFC 3261, RFC 3428, RFC 4975

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8591

Mobile messaging applications used with the Session InitiationProtocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet MailExtensions (S/MIME). It updates and provides clarifications for RFCs3261, 3428, and 4975.

RFC 8592 Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH)

Authors: R. Browne, A. Chilikin, T. Mizrahi.

Date: May 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8592

This document describes methods of carrying Key PerformanceIndicators (KPIs) using the Network Service Header (NSH). These methods may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.

RFC 8593 Video Traffic Models for RTP Congestion Control Evaluations

Authors: X. Zhu, S. Mena, Z. Sarker.

Date: May 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8593

This document describes two reference video traffic models for evaluating RTP congestion control algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate. The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module. Finally, the document describes how both approaches can be combined into a hybrid model.

RFC 8594 The Sunset HTTP Header Field

Authors: E. Wilde.

Date: May 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8594

This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset.

RFC 8595 An MPLS-Based Forwarding Plane for Service Function Chaining

Authors: A. Farrel, S. Bryant, J. Drake.

Date: June 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8595

This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. This approach does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks.

RFC 8596 MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)

Authors: A. Malis, S. Bryant, J. Halpern, W. Henderickx.

Date: June 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8596

This document describes how to use a Service Function Forwarder (SFF)Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header(NSH) between an MPLS label stack and the NSH original packet/frame.This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network. The label is also used to select between multiple SFFs in the destination MPLS node.

RFC 8597 Cooperating Layered Architecture for Software-Defined Networking (CLAS)

Authors: LM. Contreras, CJ. Bernardos, D. Lopez, M. Boucadair, P. Iovanna.

Date: May 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8597

Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities.
This document describes an approach called Cooperating LayeredArchitecture for Software-Defined Networking (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path.

RFC 8598 Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: T. Pauly, P. Wouters.

Date: May 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8598

This document defines two Configuration Payload Attribute Types(INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet KeyExchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations.

RFC 8599 Push Notification with the Session Initiation Protocol (SIP)

Authors: C. Holmberg, M. Arnold.

Date: May 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8599

This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent(UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA. It also defines the parameters to trigger such push notification requests. The document also defines new feature-capability indicators that can be used to indicate support of this mechanism.

RFC 8600 Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange

Authors: N. Cam-Winget, Ed., S. Appala, S. Pope, P. Saint-Andre.

Date: June 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8600

This document describes how to use the Extensible Messaging andPresence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network- connected devices, primarily for the purpose of communication amongComputer Security Incident Response Teams and associated entities.To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF).

RFC 8601 Message Header Field for Indicating Message Authentication Status

Authors: M. Kucherawy.

Date: May 2019

Formats: txt html json

Obsoletes: RFC 7601

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8601

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.
This document obsoletes RFC 7601.

RFC 8602 Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses

Authors: J. Arkko, T. Hardie.

Date: July 2019

Formats: txt json html

Updates: RFC 3219

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8602

This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information.
This memo updates RFC 3219.

RFC 8603 Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile

Authors: M. Jenkins, L. Zieglar.

Date: May 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8603

This document specifies a base profile for X.509 v3 Certificates andX.509 v2 Certificate Revocation Lists (CRLs) for use with the UnitedStates National Security Agency's Commercial National SecurityAlgorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US NationalSecurity Systems that employ such X.509 certificates. US NationalSecurity Systems are described in NIST Special Publication 800-59.It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

RFC 8604 Interconnecting Millions of Endpoints with Segment Routing

Authors: C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., W. Henderickx, D. Cooper.

Date: June 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8604

This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use case can be applied to the interconnection of massive-scale Data Centers (DCs) and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries. This may be achieved by the inherently scaleable nature of Segment Routing and the design proposed in this document.

RFC 8605 vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)

Authors: S. Hollenbeck, R. Carney.

Date: May 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8605

This document defines extensions to the vCard data format for representing and exchanging contact information used to implement theInternet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP).The property and parameter defined here are used to add values toRDAP responses that are consistent with ICANN policies.

RFC 8606 ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field

Authors: R. Jesske.

Date: June 2019

Formats: txt json html

Updates: RFC 3326

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8606

The SIP Reason header field is defined to carry ISUP (ISDN User Part) cause values as well as SIP response codes. Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN (Public Switched Telephone Network) to correctly interpret the reason of release. This document updates RFC 3326 by adding a location parameter for this purpose.

RFC 8607 Calendaring Extensions to WebDAV (CalDAV): Managed Attachments

Authors: C. Daboo, A. Quillaud, K. Murchison, Ed..

Date: June 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8607

This specification adds an extension to the Calendaring Extensions toWebDAV (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server.
This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP.

RFC 8608 BGPsec Algorithms, Key Formats, and Signature Formats

Authors: S. Turner, O. Borchert.

Date: June 2019

Formats: txt html json

Obsoletes: RFC 8208

Updates: RFC 7935

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8608

This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208("BGPsec Algorithms, Key Formats, and Signature Formats") by addingDocumentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading.
This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.

RFC 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 8610 Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures

Authors: H. Birkholz, C. Vigano, C. Bormann.

Date: June 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8610

This document proposes a notational convention to express ConciseBinary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR orJSON.

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 8612 DDoS Open Threat Signaling (DOTS) Requirements

Authors: A. Mortensen, T. Reddy, R. Moskowitz.

Date: May 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8612

This document defines the requirements for the Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.

RFC 8613 Object Security for Constrained RESTful Environments (OSCORE)

Authors: G. Selander, J. Mattsson, F. Palombini, L. Seitz.

Date: July 2019

Formats: txt json html

Updates: RFC 7252

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8613

This document defines Object Security for Constrained RESTfulEnvironments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR ObjectSigning and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP.OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.
Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.

RFC 8614 Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS)

Authors: R. Singh, K. Kompella, S. Palislamovic.

Date: June 2019

Formats: txt html json

Updates: RFC 4761

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8614

This document updates the meaning of the Control Flags field in the"Layer2 Info Extended Community" used for BGP Virtual Private LANService (VPLS) Network Layer Reachability Information (NLRI) as defined in RFC 4761. This document updates RFC 4761.

RFC 8615 Well-Known Uniform Resource Identifiers (URIs)

Authors: M. Nottingham.

Date: May 2019

Formats: txt html json

Obsoletes: RFC 5785

Updates: RFC 7230, RFC 7595

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8615

This memo defines a path prefix for "well-known locations","/.well-known/", in selected Uniform Resource Identifier (URI) schemes.
In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.

RFC 8616 Email Authentication for Internationalized Mail

Authors: J. Levine.

Date: June 2019

Formats: txt json html

Updates: RFC 6376, RFC 7208, RFC 7489

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8616

Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail(DKIM) (RFC 6376), and Domain-based Message Authentication,Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS.In internationalized email, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications.

RFC 8617 The Authenticated Received Chain (ARC) Protocol

Authors: K. Andersen, B. Long, Ed., S. Blank, Ed., M. Kucherawy, Ed..

Date: July 2019

Formats: txt json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8617

The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling.
ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.
ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet MailHandlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries.

RFC 8618 Compacted-DNS (C-DNS): A Format for DNS Packet Capture

Authors: J. Dickinson, J. Hague, S. Dickinson, T. Manderson, J. Bond.

Date: September 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8618

This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the fullDNS message contents along with the most useful transport metadata.It is intended to assist with the development of DNS traffic- monitoring applications.

RFC 8619 Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF)

Authors: R. Housley.

Date: June 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8619

RFC 5869 specifies the HMAC-based Extract-and-Expand Key DerivationFunction (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions.

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 8621 The JSON Meta Application Protocol (JMAP) for Mail

Authors: N. Jenkins, C. Newman.

Date: August 2019

Formats: txt html json

Updates: RFC 5788

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8621

This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP).Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client.

RFC 8622 A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services

Authors: R. Bless.

Date: June 2019

Formats: txt json html

Obsoletes: RFC 3662

Updates: RFC 4594, RFC 8325

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8622

This document specifies properties and characteristics of a Lower-Effort Per-Hop Behavior (LE PHB). The primary objective of this LEPHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for thisPHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LEPHB.
This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.

RFC 8623 Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)

Authors: U. Palle, D. Dhody, Y. Tanaka, V. Beeram.

Date: June 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8623

The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation ElementCommunication Protocol (PCEP) so as to enable the usage of a statefulPCE capability in supporting P2MP TE LSPs.

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 8625 Ethernet Traffic Parameters with Availability Information

Authors: H. Long, M. Ye, Ed., G. Mirsky, Ed., A. D'Alessandro, H. Shah.

Date: August 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8625

A packet-switching network may contain links with variable bandwidths(e.g., copper and radio). The bandwidth of such links is sensitive to the external environment (e.g., climate). Availability is typically used to describe these links when doing network planning.This document introduces an optional Bandwidth Availability TLV inRSVP-TE signaling. This extension can be used to set up a GMPLSLabel Switched Path (LSP) in conjunction with the EthernetSENDER_TSPEC object.

RFC 8627 RTP Payload Format for Flexible Forward Error Correction (FEC)

Authors: M. Zanaty, V. Singh, A. Begen, G. Mandyam.

Date: July 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8627

This document defines new RTP payload formats for the Forward ErrorCorrection (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP.These parity codes are systematic codes (Flexible FEC, or "FLEXFEC"), where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes that are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity. The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications and offer several improvements. Due to these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.

RFC 8628 OAuth 2.0 Device Authorization Grant

Authors: W. Denniss, J. Bradley, M. Jones, H. Tschofenig.

Date: August 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8628

The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

RFC 8629 Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension

Authors: B. Cheng, L. Berger, Ed..

Date: July 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8629

This document defines an extension to the Dynamic Link ExchangeProtocol (DLEP) that enables the reporting and control of multi-hop forwarding by DLEP-capable modems.

RFC 8630 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator

Authors: G. Huston, S. Weiler, G. Michaelson, S. Kent, T. Bruijnzeels.

Date: August 2019

Formats: txt html json

Obsoletes: RFC 7730

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8630

This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) CertificationAuthority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL.Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate.
This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform ResourceIdentifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC7230) as the scheme.

RFC 8631 Link Relation Types for Web Services

Authors: E. Wilde.

Date: July 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8631

Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web services" or "Web APIs". This specification defines link relations that represent relationships from Web services or APIs to resources that provide documentation, descriptions, metadata, or status information for these resources. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. Metadata provides information about a service's context. This specification also defines a link relation to identify status resources that are used to represent information about service status.

RFC 8632 A YANG Data Model for Alarm Management

Authors: S. Vallin, M. Bjorklund.

Date: September 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8632

This document defines a YANG module for alarm management. It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards.

RFC 8633 Network Time Protocol Best Current Practices

Authors: D. Reilly, H. Stenn, D. Sibold.

Date: July 2019

Formats: txt json html

Also: BCP 0223

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8633

The Network Time Protocol (NTP) is one of the oldest protocols on theInternet and has been widely used since its initial publication.This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905.

RFC 8634 BGPsec Router Certificate Rollover

Authors: B. Weis, R. Gagliano, K. Patel.

Date: August 2019

Formats: txt html json

Also: BCP 0224

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8634

Certification Authorities (CAs) within the Resource Public KeyInfrastructure (RPKI) manage BGPsec router certificates as well asRPKI certificates. The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec UPDATE messages verified with those router public keys. This document describes a safe rollover process, and it discusses when and why the rollover of BGPsec router certificates is necessary. When this rollover process is followed, the rollover will be performed without routing information being lost.

RFC 8635 Router Keying for BGPsec

Authors: R. Bush, S. Turner, K. Patel.

Date: August 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8635

BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.

RFC 8636 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility

Authors: L. Hornquist Astrand, L. Zhu, M. Cullen, G. Hudson.

Date: July 2019

Formats: txt json html

Updates: RFC 4556

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8636

This document updates the Public Key Cryptography for InitialAuthentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. ThePKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client'sX.509 certificates are made discoverable.
These changes provide preemptive protection against vulnerabilities discovered in the future in any specific cryptographic algorithm and allow incremental deployment of newer algorithms.

RFC 8637 Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)

Authors: D. Dhody, Y. Lee, D. Ceccarelli.

Date: July 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8637

Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.
The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. ThePCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path ComputationElement Communication Protocol (PCEP).
This document examines the applicability of PCE to the ACTN framework.

RFC 8638 IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks

Authors: M. Xu, Y. Cui, J. Wu, S. Yang, C. Metz.

Date: September 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8638

During the transition to IPv6, there are scenarios where a backbone network internally running one IP address family (referred to as the internal IP or I-IP family) connects client networks running anotherIP address family (referred to as the external IP or E-IP family).In such cases, the I-IP backbone needs to offer both unicast and multicast transit services to the client E-IP networks.
This document describes a mechanism for supporting multicast across backbone networks where the I-IP and E-IP protocol families differ.The document focuses on the IPv4-over-IPv6 scenario, due to lack of real-world use cases for the IPv6-over-IPv4 scenario.

RFC 8639 Subscription to YANG Notifications

Authors: E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy.

Date: September 2019

Formats: txt html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8639

This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.

RFC 8640 Dynamic Subscription to YANG Events and Datastores over NETCONF

Authors: E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy.

Date: September 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8640

This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.

RFC 8641 Subscription to YANG Notifications for Datastore Updates

Authors: A. Clemm, E. Voit.

Date: September 2019

Formats: txt json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8641

This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.

RFC 8642 Policy Behavior for Well-Known BGP Communities

Authors: J. Borkenhagen, R. Bush, R. Bonica, S. Bayraktar.

Date: August 2019

Formats: txt html json

Updates: RFC 1997

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8642

Well-known BGP communities are manipulated differently across various current implementations, resulting in difficulties for operators.Network operators should deploy consistent community handling across their networks while taking the inconsistent behaviors from the various BGP implementations into consideration. This document recommends specific actions to limit future inconsistency: namely,BGP implementors must not create further inconsistencies from this point forward. These behavioral changes, though subtle, actually update RFC 1997.

RFC 8643 An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)

Authors: A. Johnston, B. Aboba, A. Hutton, R. Jesske, T. Stach.

Date: August 2019

Formats: txt html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8643

Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined inRFC 7435, applied to the Real-time Transport Protocol (RTP). OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance and is not required. OSRTP does not require Session Description Protocol (SDP) extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets. OSRTP is not specific to any key management technique for Secure RTP (SRTP). OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state.

RFC 8645 Re-keying Mechanisms for Symmetric Keys

Authors: S. Smyshlyaev, Ed..

Date: August 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8645

A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM,CBC, CFB, and OMAC.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

RFC 8649 Hash Of Root Key Certificate Extension

Authors: R. Housley.

Date: August 2019

Formats: txt json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8649

This document specifies the Hash Of Root Key certificate extension.This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root CertificationAuthority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one.

RFC 8650 Dynamic Subscription to YANG Events and Datastores over RESTCONF

Authors: E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman.

Date: November 2019

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8650

This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.

RFC 8651 Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension

Authors: B. Cheng, D. Wiggins, L. Berger, Ed..

Date: October 2019

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8651

This document defines an extension to the Dynamic Link ExchangeProtocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router.

RFC 8652 A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)

Authors: X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter.

Date: November 2019

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8652

This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and MulticastListener Discovery (MLD) devices.

RFC 8653 On-Demand Mobility Management

Authors: A. Yegin, D. Moses, S. Jeon.

Date: October 2019

Formats: txt xml html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8653

Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies, as described in RFC 7333. This document defines a new concept of enabling applications to influence the network's mobility services (session continuity and/or IP address reachability) on a per-socket basis, and suggests extensions to the networking stack's API to accommodate this concept.

RFC 8654 Extended Message Support for BGP

Authors: R. Bush, K. Patel, D. Ward.

Date: October 2019

Formats: txt xml pdf json html

Updates: RFC 4271

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8654

The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support new Address FamilyIdentifiers (AFIs), Subsequent AFIs (SAFIs), and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specification by extending the maximum message size from 4,096 octets to 65,535 octets for all messages except for OPEN and KEEPALIVE messages.

RFC 8655 Deterministic Networking Architecture

Authors: N. Finn, P. Thubert, B. Varga, J. Farkas.

Date: October 2019

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8655

This document provides the overall architecture for DeterministicNetworking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time-Sensitive Networking (TSN) as defined by IEEE 802.1.

RFC 8656 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)

Authors: T. Reddy, Ed., A. Johnston, Ed., P. Matthews, J. Rosenberg.

Date: February 2020

Formats: txt html pdf json xml

Obsoletes: RFC 5766, RFC 6156

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8656

If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. 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 "TraversalUsing Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from 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 InteractiveConnectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE.
This document obsoletes RFCs 5766 and 6156.

RFC 8657 Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding

Authors: H. Landau.

Date: November 2019

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8657

The Certification Authority Authorization (CAA) DNS record allows a domain to communicate an issuance policy to Certification Authorities(CAs) but only allows a domain to define a policy with CA-level granularity. However, the CAA specification (RFC 8659) also provides facilities for an extension to admit a more granular, CA-specific policy. This specification defines two such parameters: one allowing specific accounts of a CA to be identified by URIs and one allowing specific methods of domain control validation as defined by theAutomatic Certificate Management Environment (ACME) protocol to be required.

RFC 8658 RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)

Authors: S. Jiang, Ed., Y. Fu, Ed., C. Xie, T. Li, M. Boucadair, Ed..

Date: November 2019

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8658

IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients forLightweight 4over6, Mapping of Address and Port with Encapsulation(MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in anAuthentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly.
This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered.

RFC 8659 DNS Certification Authority Authorization (CAA) Resource Record

Authors: P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews.

Date: November 2019

Formats: txt json pdf xml html

Obsoletes: RFC 6844

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8659

The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more CertificationAuthorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue.This document defines the syntax of the CAA record and rules for processing CAA records by CAs.
This document obsoletes RFC 6844.

RFC 8660 Segment Routing with the MPLS Data Plane

Authors: A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski, R. Shakir.

Date: December 2019

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8660

Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack.This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).

RFC 8661 Segment Routing MPLS Interworking with LDP

Authors: A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski.

Date: December 2019

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8661

A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows enforcing a flow through any topological path while maintaining per-flow state only at the ingress node to theSR domain.
The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This document describes how Segment Routing MPLS operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist.

RFC 8662 Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels

Authors: S. Kini, K. Kompella, S. Sivabalan, S. Litkowski, R. Shakir, J. Tantsura.

Date: December 2019

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8662

Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the Multiprotocol LabelSwitching (MPLS) data plane. Entropy labels (ELs) are used in MPLS to improve load-balancing. This document examines and describes howELs are to be applied to Segment Routing MPLS.

RFC 8663 MPLS Segment Routing over IP

Authors: X. Xu, S. Bryant, A. Farrel, S. Hassan, W. Henderickx, Z. Li.

Date: December 2019

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8663

MPLS Segment Routing (SR-MPLS) is a method of source routing a packet through an MPLS data plane by imposing a stack of MPLS labels on the packet to specify the path together with any packet-specific instructions to be executed on it. SR-MPLS can be leveraged to realize a source-routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source-routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations.
This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use ofSR-MPLS label stacks and IP encapsulation/tunneling such as MPLS- over-UDP as defined in RFC 7510.

RFC 8664 Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing

Authors: S. Sivabalan, C. Filsfils, J. Tantsura, W. Henderickx, J. Hardwick.

Date: December 2019

Formats: txt json pdf xml html

Updates: RFC 8408

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8664

Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP orRSVP-TE). It depends only on "segments" that are advertised by link- state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree(SPT), an explicit configuration, or a Path Computation Element(PCE). This document specifies extensions to the Path ComputationElement Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as aPath Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.
This document updates RFC 8408.

RFC 8665 OSPF Extensions for Segment Routing

Authors: P. Psenak, Ed., S. Previdi, Ed., C. Filsfils, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura.

Date: December 2019

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8665

Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
This document describes the OSPFv2 extensions required for SegmentRouting.

RFC 8666 OSPFv3 Extensions for Segment Routing

Authors: P. Psenak, Ed., S. Previdi, Ed..

Date: December 2019

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8666

Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
This document describes the OSPFv3 extensions required for SegmentRouting with the MPLS data plane.

RFC 8667 IS-IS Extensions for Segment Routing

Authors: S. Previdi, Ed., L. Ginsberg, Ed., C. Filsfils, A. Bashandy, H. Gredler, B. Decraene.

Date: December 2019

Formats: txt xml html pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8667

Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.

RFC 8668 Advertising Layer 2 Bundle Member Link Attributes in IS-IS

Authors: L. Ginsberg, Ed., A. Bashandy, C. Filsfils, M. Nanduri, E. Aries.

Date: December 2019

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8668

There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required.
This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members.

RFC 8669 Segment Routing Prefix Segment Identifier Extensions for BGP

Authors: S. Previdi, C. Filsfils, A. Lindem, Ed., A. Sreekantiah, H. Gredler.

Date: December 2019

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8669

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. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs). Each SID represents a topological or service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An "SR domain" is defined as a single administrative domain for global SID assignment.
This document defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGPPrefix-SIDs) and the specification for SR-MPLS SIDs.

RFC 8670 BGP Prefix Segment in Large-Scale Data Centers

Authors: C. Filsfils, Ed., S. Previdi, G. Dawra, E. Aries, P. Lapukhov.

Date: December 2019

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8670

This document describes the motivation for, and benefits of, applyingSegment Routing (SR) in BGP-based large-scale data centers. It describes the design to deploy SR in those data centers for both theMPLS and IPv6 data planes.

RFC 8671 Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)

Authors: T. Evens, S. Bayraktar, P. Lucente, P. Mi, S. Zhuang.

Date: November 2019

Formats: txt json pdf xml html

Updates: RFC 7854

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8671

The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out.

RFC 8672 TLS Server Identity Pinning with Tickets

Authors: Y. Sheffer, D. Migault.

Date: October 2019

Formats: txt html xml pdf json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8672

Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate. These mechanisms are either not widely deployed or limited to public web browsing.
This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership of the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions are required.

RFC 8673 HTTP Random Access and Live Content

Authors: C. Pratt, D. Thakore, B. Stark.

Date: November 2019

Formats: txt html json xml pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8673

To accommodate byte-range requests for content that has data appended over time, this document defines semantics that allow an HTTP client and a server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and end at an indeterminate offset.

RFC 8674 The "safe" HTTP Preference

Authors: M. Nottingham.

Date: December 2019

Formats: txt json xml html pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8674

This specification defines a preference for HTTP requests that expresses a desire to avoid objectionable content, according to the definition of that term by the origin server.
This specification does not define a precise semantic for "safe".Rather, the term is interpreted by the server and within the scope of each web site that chooses to act upon this information.
Support for this preference by clients and servers is optional.

RFC 8675 A YANG Data Model for Tunnel Interface Types

Authors: M. Boucadair, I. Farrer, R. Asati.

Date: November 2019

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8675

This document specifies the initial version of a YANG module "iana- tunnel-type", which contains a collection of IANA-maintained YANG identities used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA website.
Tunnel type values are not directly added to the Tunnel InterfaceTypes YANG module; they must instead be added to the "tunnelType"IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly.
Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed.

RFC 8676 YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires

Authors: I. Farrer, Ed., M. Boucadair, Ed..

Date: November 2019

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8676

This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and CustomerPremises Equipment for the Lightweight 4over6, Mapping of Address andPort with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms.

RFC 8677 Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework

Authors: D. Trossen, D. Purkayastha, A. Rahman.

Date: November 2019

Formats: txt pdf xml html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8677

Adoption of cloud and fog technology allows operators to deploy a single "Service Function" (SF) to multiple "execution locations".The decision to steer traffic to a specific location may change frequently based on load, proximity, etc. Under the current ServiceFunction Chaining (SFC) framework, steering traffic dynamically to the different execution endpoints requires a specific "rechaining", i.e., a change in the service function path reflecting the differentIP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify rechaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path (SFP) from the specific execution endpoints. This can be done by identifying the SFs using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions, and protocol details in the Service Function Forwarder (SFF) to handle name-based relationships.
This document presents InterDigital's approach to name-based SFC. It does not represent IETF consensus and is presented here so that theSFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers.

RFC 8678 Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions

Authors: F. Baker, C. Bowers, J. Linkova.

Date: December 2019

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8678

Connecting an enterprise site to multiple ISPs over IPv6 using provider-assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs.
This document examines currently available mechanisms for providing a solution to this problem for a broad range of enterprise topologies.It covers the behavior of routers to forward traffic by taking into account source address, and it covers the behavior of hosts to select appropriate default source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this document also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator.

RFC 8679 MPLS Egress Protection Framework

Authors: Y. Shen, M. Jeganathan, B. Decraene, H. Gredler, C. Michel, H. Chen.

Date: December 2019

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8679

This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure.

RFC 8680 Forward Error Correction (FEC) Framework Extension to Sliding Window Codes

Authors: V. Roca, A. Begen.

Date: January 2020

Formats: txt json pdf html xml

Updates: RFC 6363

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8680

RFC 6363 describes a framework for using Forward Error Correction(FEC) codes 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. However, FECFRAME as per RFC 6363 is restricted to block FEC codes. This document updates RFC 6363 to support FEC codes based on a sliding encoding window, in addition to block FEC codes, in a backward-compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency.

RFC 8681 Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME

Authors: V. Roca, B. Teibi.

Date: January 2020

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8681

This document describes two fully specified Forward ErasureCorrection (FEC) Schemes for Sliding Window Random Linear Codes(RLC), one for RLC over the Galois Field (a.k.a., Finite Field)GF(2), a second one for RLC over the Galois Field GF(2^(8)), each time with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to Sliding Window FEC Codes. These Sliding Window FEC Codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these Sliding Window FEC Codes offer key advantages with real- time flows in terms of reduced FEC-related latency while often providing improved packet erasure recovery capabilities.

RFC 8682 TinyMT32 Pseudorandom Number Generator (PRNG)

Authors: M. Saito, M. Matsumoto, V. Roca, Ed., E. Baccelli.

Date: January 2020

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8682

This document describes the TinyMT32 Pseudorandom Number Generator(PRNG), which produces 32-bit pseudorandom unsigned integers and aims at having a simple-to-use and deterministic solution. This PRNG is a small-sized variant of the Mersenne Twister (MT) PRNG. The main advantage of TinyMT32 over MT is the use of a small internal state, compatible with most target platforms that include embedded devices, while keeping reasonably good randomness that represents a significant improvement compared to the Park-Miller LinearCongruential PRNG. However, neither the TinyMT nor MT PRNG is meant to be used for cryptographic applications.

RFC 8683 Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks

Authors: J. Palet Martinez.

Date: November 2019

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8683

This document describes how Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed in an IPv6 network -- whether it's cellular ISP, broadbandISP, or enterprise -- and the possible optimizations. This document also discusses issues to be considered when having IPv6-only connectivity, such as: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or applications.

RFC 8684 TCP Extensions for Multipath Operation with Multiple Addresses

Authors: A. Ford, C. Raiciu, M. Handley, O. Bonaventure, C. Paasch.

Date: March 2020

Formats: txt json xml pdf html

Obsoletes: RFC 6824

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8684

TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure.
Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.
This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience.

RFC 8685 Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture

Authors: F. Zhang, Q. Zhao, O. Gonzalez de Dios, R. Casellas, D. King.

Date: December 2019

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8685

The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains.
This document defines extensions to the Path Computation ElementCommunication Protocol (PCEP) to support H-PCE procedures.

RFC 8686 Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery

Authors: S. Kiesel, M. Stiemerling.

Date: February 2020

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8686

The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before anALTO client can ask for guidance, it needs to discover one or moreALTO servers that can provide suitable guidance.
In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be necessary to discover an ALTO server outside of the ALTO client's own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery.
Technically, the procedure specified in this document takes oneIP address or prefix and a U-NAPTR Service Parameter (typically,"ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees) and returns one or more URIs of information resources related to that IP address or prefix.

RFC 8687 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels

Authors: A. Smirnov, A. Retana, M. Barnes.

Date: November 2019

Formats: txt html pdf xml json

Updates: RFC 5786

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8687

When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label Switching (MPLS) TE Label SwitchedPath (LSP) infrastructure may be duplicated, even if the destinationIPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This issue is solved by advertising cross- address family (X-AF) OSPF TE information.
This document describes an update to RFC 5786 that allows for the easy identification of a router's local X-AF IP addresses.

RFC 8688 A Session Initiation Protocol (SIP) Response Code for Rejected Calls

Authors: E.W. Burger, B. Nagda.

Date: December 2019

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8688

This document defines the 608 (Rejected) Session Initiation Protocol(SIP) response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code in which a human at the target User Agent Server indicates the user did not want the call. In some jurisdictions, this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked.

RFC 8689 SMTP Require TLS Option

Authors: J. Fenton.

Date: November 2019

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8689

The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and a message header field, TLS-Required. If the REQUIRETLS option or TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed or by requesting that recipient-side policy mechanisms such as MTA-STS and DNS-BasedAuthentication of Named Entities (DANE) be ignored when relaying a message for which security is unimportant.

RFC 8690 Clarification of Segment ID Sub-TLV Length for RFC 8287

Authors: N. Nainar, C. Pignataro, F. Iqbal, A. Vainshtein.

Date: December 2019

Formats: txt json html xml pdf

Updates: RFC 8287

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8690

RFC 8287 defines the extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers(SIDs) with the MPLS data plane. RFC 8287 proposes three TargetForwarding Equivalence Class (FEC) Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs. This ambiguity has resulted in interoperability issues.
This document updates RFC 8287 by clarifying the length of each of the Segment ID sub-TLVs defined in RFC 8287.

RFC 8691 Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11

Authors: N. Benamar, J. Härri, J. Lee, T. Ernst.

Date: December 2019

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8691

This document provides methods and settings for using IPv6 to communicate among nodes within range of one another over a singleIEEE 802.11-OCB link. Support for these methods and settings require minimal changes to existing stacks. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 over more complex scenarios are not covered in this specification and are a subject for future work.

RFC 8692 Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs

Authors: P. Kampanakis, Q. Dang.

Date: December 2019

Formats: txt pdf xml html json

Updates: RFC 3279

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8692

Digital signatures are used to sign messages, X.509 certificates, andCertificate Revocation Lists (CRLs). This document updates the"Algorithms and Identifiers for the Internet X.509 Public KeyInfrastructure Certificate and Certificate Revocation List (CRL)Profile" (RFC 3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature andElliptic Curve Digital Signature Algorithm (ECDSA) signature algorithms. The conventions for the associated subject public keys are also described.

RFC 8693 OAuth 2.0 Token Exchange

Authors: M. Jones, A. Nadalin, B. Campbell, Ed., J. Bradley, C. Mortimore.

Date: January 2020

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8693

This specification defines a protocol for an HTTP- and JSON-basedSecurity Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

RFC 8694 Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering

Authors: D. King, H. Zheng.

Date: December 2019

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8694

The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-Autonomous System (multi-AS)Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)Traffic-Engineered (TE) networks.
This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks.

RFC 8695 A YANG Data Model for the Routing Information Protocol (RIP)

Authors: X. Liu, P. Sarda, V. Choudhary.

Date: February 2020

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8695

This document describes a data model for the management of theRouting Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA).

RFC 8696 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)

Authors: R. Housley.

Date: December 2019

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8696

The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms if the existing syntax does not accommodate them. This document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key.

RFC 8697 Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)

Authors: I. Minei, E. Crabbe, S. Sivabalan, H. Ananthakrishnan, D. Dhody, Y. Tanaka.

Date: January 2020

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8697

This document introduces a generic mechanism to create a grouping ofLabel Switched Paths (LSPs) in the context of a Path ComputationElement (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes(such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.

RFC 8698 Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media

Authors: X. Zhu, R. Pan, M. Ramalho, S. Mena.

Date: February 2020

Formats: txt json xml html pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8698

This document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing. In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead.

RFC 8699 Coupled Congestion Control for RTP Media

Authors: S. Islam, M. Welzl, S. Gjessing.

Date: January 2020

Formats: txt json xml html pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8699

When multiple congestion-controlled Real-time Transport Protocol(RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the number of changes needed to existing RTP applications. This document also specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other congestion control algorithms.

RFC 8700 Fifty Years of RFCs

Authors: H. Flanagan, Ed..

Date: December 2019

Formats: txt json pdf xml html

Updates: RFC 2555, RFC 5540

Status: INFORMATIONAL

DOI: 10.17487/RFC 8700

This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates the perspectives offered in RFCs 2555 and 5540.

RFC 8701 Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility

Authors: D. Benjamin.

Date: January 2020

Formats: txt json html pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8701

This document describes GREASE (Generate Random Extensions AndSustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.

RFC 8702 Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)

Authors: P. Kampanakis, Q. Dang.

Date: January 2020

Formats: txt html xml pdf json

Updates: RFC 3370

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8702

This document updates the "Cryptographic Message Syntax (CMS)Algorithms" (RFC 3370) and describes the conventions for using theSHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme(RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA).The conventions for the associated signer public keys in CMS are also described.

RFC 8703 Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension

Authors: R. Taylor, S. Ratliff.

Date: February 2020

Formats: txt xml html pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8703

The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol (RFC8175) assumes that every modem in the radio network has an attachedDLEP router and requires that the Media Access Control (MAC) address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination.
This document describes a DLEP extension that allows modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain.

RFC 8704 Enhanced Feasible-Path Unicast Reverse Path Forwarding

Authors: K. Sriram, D. Montgomery, J. Haas.

Date: February 2020

Formats: txt json xml pdf html

Updates: RFC 3704

Also: BCP 0084

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8704

This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38).Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704).However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible- path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704.

RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

Authors: B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt.

Date: February 2020

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8705

This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security(TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.

RFC 8706 Restart Signaling for IS-IS

Authors: L. Ginsberg, P. Wells.

Date: February 2020

Formats: txt html pdf json xml

Obsoletes: RFC 5306

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8706

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the DOWN state while still correctly initiating database synchronization.
This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding-plane state. This allows the neighbors to maintain their adjacencies until the router has restarted but also allows the neighbors to bring the adjacencies down in the event of other topology changes.
This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol DataUnit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization while minimizing transient routing disruption when a router starts.
This document obsoletes RFC 5306.

RFC 8707 Resource Indicators for OAuth 2.0

Authors: B. Campbell, J. Bradley, H. Tschofenig.

Date: February 2020

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8707

This document specifies an extension to the OAuth 2.0 AuthorizationFramework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.

RFC 8708 Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)

Authors: R. Housley.

Date: February 2020

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8708

This document specifies the conventions for using the HierarchicalSignature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.

RFC 8709 Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol

Authors: B. Harris, L. Velvindron.

Date: February 2020

Formats: txt json html pdf xml

Updates: RFC 4253

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8709

This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol.Accordingly, this RFC updates RFC 4253.

RFC 8710 Multipart Content-Format for the Constrained Application Protocol (CoAP)

Authors: T. Fossati, K. Hartke, C. Bormann.

Date: February 2020

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8710

This memo defines application/multipart-core, an application- independent media type that can be used to combine representations of zero or more different media types (each with a ConstrainedApplication Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead.

RFC 8711 Structure of the IETF Administrative Support Activity, Version 2.0

Authors: B. Haberman, J. Hall, J. Livingood.

Date: February 2020

Formats: txt json html xml pdf

Obsoletes: RFC 4071, RFC 4333, RFC 7691

Also: BCP 0101

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8711

The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe theIETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLCBoard (IETF LLC Board), the IETF Executive Director, and the InternetSociety in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.
This document obsoletes RFC 4071, RFC 4333, and RFC 7691.

RFC 8712 The IETF-ISOC Relationship

Authors: G. Camarillo, J. Livingood.

Date: February 2020

Formats: txt html pdf xml json

Obsoletes: RFC 2031

Status: INFORMATIONAL

DOI: 10.17487/RFC 8712

This document summarizes the Internet Engineering Task Force (IETF) -Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in2018. The IASA was revised under a new "IASA 2.0" structure by theIASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031.

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 8714 Update to the Process for Selection of Trustees for the IETF Trust

Authors: J. Arkko, T. Hardie.

Date: February 2020

Formats: txt pdf json xml html

Obsoletes: RFC 4371

Also: BCP 0101

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8714

This memo updates the process for selection of Trustees for the IETFTrust. Previously, the IETF Administrative Oversight Committee(IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETFAdministrative Support Activity (IASA). This memo specifies that theTrustees shall be selected separately.
This memo obsoletes RFC 4371. The changes relate only to the selection of Trustees. All other aspects of the IETF Trust remain as they are today.

RFC 8715 IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust

Authors: J. Arkko.

Date: February 2020

Formats: txt pdf json xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8715

This document captures the rationale for the changes introduced inRFC 8714, "Update to the Process for Selection of Trustees for theIETF Trust".
At the time RFC 8714 was published, the changes to the IETFAdministrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF Trust because members of the IETF AdministrativeOversight Committee (IAOC), which was being phased out, had served asTrustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update.

RFC 8716 Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC

Authors: P. Resnick, A. Farrel.

Date: February 2020

Formats: txt html xml pdf json

Updates: RFC 7776

Also: BCP 0025

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8716

The IETF Anti-Harassment Procedures are described in RFC 7776.
The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms.
RFC 7776 contained updates to RFC 7437. RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates.

RFC 8717 IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology

Authors: J. Klensin, Ed..

Date: February 2020

Formats: txt html json xml pdf

Updates: RFC 2028, RFC 2418, RFC 3005, RFC 3710, RFC 3929, RFC 4633, RFC 6702

Also: BCP 0101

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8717

In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes.

RFC 8718 IETF Plenary Meeting Venue Selection Process

Authors: E. Lear, Ed..

Date: February 2020

Formats: txt json xml pdf html

Also: BCP 0226

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8718

The IETF Administration Support Activity (IASA) is responsible for arranging the selection and operation of the IETF plenary meeting venue. This memo specifies IETF community requirements for meeting venues, including hotels and meeting space. It also directs the IASA to make available additional process documents that describe the current meeting selection process.

RFC 8719 High-Level Guidance for the Meeting Policy of the IETF

Authors: S. Krishnan.

Date: February 2020

Formats: txt json html xml pdf

Also: BCP 0226

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8719

This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.

RFC 8720 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries

Authors: R. Housley, Ed., O. Kolkman, Ed..

Date: February 2020

Formats: txt json pdf xml html

Obsoletes: RFC 7500

Status: INFORMATIONAL

DOI: 10.17487/RFC 8720

This document provides principles for the operation of InternetAssigned Numbers Authority (IANA) registries.

RFC 8721 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents

Authors: J. Halpern, Ed..

Date: February 2020

Formats: txt pdf xml json html

Obsoletes: RFC 5377

Status: INFORMATIONAL

DOI: 10.17487/RFC 8721

Contributors grant intellectual property rights to the IETF. TheIETF Trust holds and manages those rights on behalf of the IETF. TheTrustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts andRFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETFContributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative OversightCommittee (IAOC), which was part of the IETF Administrative SupportActivity (IASA).

RFC 8722 Defining the Role and Function of IETF Protocol Parameter Registry Operators

Authors: D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed..

Date: February 2020

Formats: txt html json xml pdf

Obsoletes: RFC 6220

Status: INFORMATIONAL

DOI: 10.17487/RFC 8722

Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document obsoletes RFC 6220 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.

RFC 8723 Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)

Authors: C. Jennings, P. Jones, R. Barnes, A.B. Roach.

Date: April 2020

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8723

In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time TransportProtocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by- hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of futureSRTP transforms with different properties.

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 8725 JSON Web Token Best Current Practices

Authors: Y. Sheffer, D. Hardt, M. Jones.

Date: February 2020

Formats: txt json xml pdf html

Updates: RFC 7519

Also: BCP 0225

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8725

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. ThisBest Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.

RFC 8726 How Requests for IANA Action Will Be Handled on the Independent Stream

Authors: A. Farrel.

Date: November 2020

Formats: txt pdf xml html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8726

The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by theIETF and documented in RFCs developed on the IETF Stream.
The Independent Submission Stream is another source of documents that can be published as RFCs. This stream is under the care of theIndependent Submissions Editor (ISE).
This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent SubmissionStream that request actions from IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes.

RFC 8727 JSON Binding of the Incident Object Description Exchange Format

Authors: T. Takahashi, R. Danyliw, M. Suzuki.

Date: August 2020

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8727

The Incident Object Description Exchange Format (IODEF) defined inRFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary ObjectRepresentation (CBOR).

RFC 8728 RFC Editor Model (Version 2)

Authors: O. Kolkman, Ed., J. Halpern, Ed., R. Hinden, Ed..

Date: February 2020

Formats: txt pdf xml json html

Obsoletes: RFC 6635

Obsoleted by: RFC 9280

Status: INFORMATIONAL

DOI: 10.17487/RFC 8728

The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFCSeries Editor, the RFC Production Center, and the RFC Publisher.Internet Architecture Board (IAB) oversight via the RFC SeriesOversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and theRSOC. This document reflects the experience gained with "RFC EditorModel (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity(IASA) and related structures with those defined by the IASA 2.0Model.

RFC 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 8731 Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448

Authors: A. Adamantiadis, S. Josefsson, M. Baushke.

Date: February 2020

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8731

This document describes the specification for using Curve25519 andCurve448 key exchange methods in the Secure Shell (SSH) protocol.

RFC 8732 Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2

Authors: S. Sorce, H. Kario.

Date: February 2020

Formats: txt html pdf xml json

Updates: RFC 4462

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8732

This document specifies additions and amendments to RFC 4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak Diffie-Hellman (DH) groups. The purpose of this specification is to modernize the cryptographic primitives used byGeneric Security Service (GSS) key exchanges.

RFC 8733 Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE

Authors: D. Dhody, Ed., R. Gandhi, Ed., U. Palle, R. Singh, L. Fang.

Date: February 2020

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8733

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.Stateful PCE extensions allow stateful control of MPLS-TE LabelSwitched Paths (LSPs) using PCEP.
The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs.

RFC 8734 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3

Authors: L. Bruckert, J. Merkle, M. Lochter.

Date: February 2020

Formats: txt json html pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8734

Elliptic Curve Cryptography (ECC) Brainpool curves were an option for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.2 but were deprecated by the IETF for use with TLS version 1.3 because they had little usage. However, these curves have not been shown to have significant cryptographical weaknesses, and there is some interest in using several of these curves in TLS1.3.
This document provides the necessary protocol mechanisms for usingECC Brainpool curves in TLS 1.3. This approach is not endorsed by the IETF.

RFC 8735 Scenarios and Simulation Results of PCE in a Native IP Network

Authors: A. Wang, X. Huang, C. Kou, Z. Li, P. Mi.

Date: February 2020

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8735

Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.
One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying thePath Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios.

RFC 8736 PIM Message Type Space Extension and Reserved Bits

Authors: S. Venaas, A. Retana.

Date: February 2020

Formats: txt xml pdf html json

Obsoletes: RFC 6166

Obsoleted by: RFC 9436

Updates: RFC 3973, RFC 5015, RFC 5059, RFC 6754, RFC 7761, RFC 8364

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8736

The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range.
This document updates RFCs 7761 and 3973 by defining the use of the currently Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the currently reserved bits for each PIM message.
This document obsoletes RFC 6166.

RFC 8737 Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension

Authors: R.B. Shoemaker.

Date: February 2020

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8737

This document specifies a new challenge for the Automated CertificateManagement Environment (ACME) protocol that allows for domain control validation using TLS.

RFC 8738 Automated Certificate Management Environment (ACME) IP Identifier Validation Extension

Authors: R.B. Shoemaker.

Date: February 2020

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8738

This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.

RFC 8739 Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)

Authors: Y. Sheffer, D. Lopez, O. Gonzalez de Dios, A. Pastor Perales, T. Fossati.

Date: March 2020

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8739

Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an AutomatedCertificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.

RFC 8740 Using TLS 1.3 with HTTP/2

Authors: D. Benjamin.

Date: February 2020

Formats: txt html pdf json xml

Obsoleted by: RFC 9113

Updates: RFC 7540

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8740

This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.

RFC 8741 Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)

Authors: A. Raghuram, A. Goddard, J. Karthik, S. Sivabalan, M. Negi.

Date: March 2020

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8741

A stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) TrafficEngineering Label Switched Paths (TE LSPs). When a PCE has stateful control over LSPs, it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A PathComputation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE.
There are use cases in which a stateful PCE may wish to obtain control of locally configured LSPs that it is aware of but have not been delegated to the PCE.
This document describes an extension to the Path Computation ElementCommunication Protocol (PCEP) to enable a PCE to make requests for such control.

RFC 8742 Concise Binary Object Representation (CBOR) Sequences

Authors: C. Bormann.

Date: February 2020

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8742

This document describes the Concise Binary Object Representation(CBOR) Sequence format and associated media type "application/cbor- seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.
Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBORSequences.

RFC 8743 Multiple Access Management Services Multi-Access Management Services (MAMS)

Authors: S. Kanugovi, F. Baboescu, J. Zhu, S. Seo.

Date: March 2020

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8743

In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.
This document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed by the authors based on their experiences in multiple standards bodies, including the IETF and the 3GPP. However, this document is not an Internet Standards Track specification, and it does not represent the consensus opinion of the IETF.
This document describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. The MAMS framework aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol for (1) flexibly selecting the best combination of access and core network paths for the uplink and downlink, and (2) determining the user-plane treatment (e.g., tunneling, encryption) and traffic distribution over the selected links, to ensure network efficiency and the best possible application performance.

RFC 8744 Issues and Requirements for Server Name Identification (SNI) Encryption in TLS

Authors: C. Huitema.

Date: July 2020

Formats: txt xml html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8744

This document describes the general problem of encrypting the ServerName Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co- tenancy" solution, and presents requirements for future TLS-layer solutions.
In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises.

RFC 8745 Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE

Authors: H. Ananthakrishnan, S. Sivabalan, C. Barth, I. Minei, M. Negi.

Date: March 2020

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8745

An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation ElementCommunication Protocol (PCEP) Multiprotocol Label Switching TrafficEngineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.

RFC 8746 Concise Binary Object Representation (CBOR) Tags for Typed Arrays

Authors: C. Bormann, Ed..

Date: February 2020

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8746

The Concise Binary Object Representation (CBOR), as defined in RFC7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
This document makes use of this extensibility to define a number ofCBOR tags for typed arrays of numeric data, as well as additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined.

RFC 8747 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)

Authors: M. Jones, L. Seitz, G. Selander, S. Erdtman, H. Tschofenig.

Date: March 2020

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8747

This specification describes how to declare in a CBOR Web Token (CWT)(which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder- of-key. This specification provides equivalent functionality to"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens(JWTs).

RFC 8748 Registry Fee Extension for the Extensible Provisioning Protocol (EPP)

Authors: R. Carney, G. Brown, J. Frakes.

Date: March 2020

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8748

Given the expansion of the DNS namespace and the proliferation of novel business models, it is desirable to provide a method forExtensible Provisioning Protocol (EPP) clients to query EPP servers for the fees and credits associated with various billable transactions and provide expected fees and credits for certain commands and objects. This document describes an EPP extension mapping for registry fees.

RFC 8749 Moving DNSSEC Lookaside Validation (DLV) to Historic Status

Authors: W. Mekking, D. Mahoney.

Date: March 2020

Formats: txt html pdf xml json

Updates: RFC 6698, RFC 6840

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8749

This document retires DNSSEC Lookaside Validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates and updates RFC 6840 by excluding the DLV registries from the trust anchor selection.

RFC 8750 Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)

Authors: D. Migault, T. Guggemos, Y. Nir.

Date: March 2020

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8750

Encapsulating Security Payload (ESP) sends an initialization vector(IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take theIV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP SequenceNumber (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case ofAES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this.

RFC 8751 Hierarchical Stateful Path Computation Element (PCE)

Authors: D. Dhody, Y. Lee, D. Ceccarelli, J. Shin, D. King.

Date: March 2020

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8751

A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients(PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests.This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.
The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of interconnected domains to be selected and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs.
Combining the capabilities of stateful PCE and the hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of stateful, but not stateless, PCEs using the hierarchical PCE architecture.

RFC 8752 Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)

Authors: M. Thomson, M. Nottingham.

Date: March 2020

Formats: txt pdf json xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8752

The Exploring Synergy between Content Aggregation and the PublisherEcosystem (ESCAPE) Workshop was convened by the Internet ArchitectureBoard (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 8753 Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions

Authors: J. Klensin, P. Fältström.

Date: April 2020

Formats: txt pdf json xml html

Updates: RFC 5892

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8753

The standards for Internationalized Domain Names in Applications(IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility withUnicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and to clarify the various relationships involved. It also makes other minor adjustments to align that document with experience.

RFC 8754 IPv6 Segment Routing Header (SRH)

Authors: C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer.

Date: March 2020

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8754

Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header(SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.

RFC 8755 Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions

Authors: M. Jenkins.

Date: March 2020

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8755

The United States Government has published the National SecurityAgency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using theUnited States National Security Agency's CNSA Suite algorithms inSecure/Multipurpose Internet Mail Extensions (S/MIME) as specified inRFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

RFC 8756 Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS

Authors: M. Jenkins, L. Zieglar.

Date: March 2020

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8756

This document specifies a profile of the Certificate Management overCMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm(CNSA) Suite published by the United States Government.
The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information.
The profile is made publicly available here for use by developers and operators of these and any other system deployments.

RFC 8757 Dynamic Link Exchange Protocol (DLEP) Latency Range Extension

Authors: B. Cheng, L. Berger, Ed..

Date: March 2020

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8757

This document defines an extension to the Dynamic Link ExchangeProtocol (DLEP) to provide the range of latency that can be experienced on a link.

RFC 8758 Deprecating RC4 in Secure Shell (SSH)

Authors: L. Velvindron.

Date: April 2020

Formats: txt html xml json pdf

Updates: RFC 4253

Also: BCP 0227

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8758

This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves RFC 4345 to Historic status.

RFC 8759 RTP Payload for Timed Text Markup Language (TTML)

Authors: J. Sandford.

Date: March 2020

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8759

This memo describes a Real-time Transport Protocol (RTP) payload format for Timed Text Markup Language (TTML), an XML-based timed text format from W3C. This payload format is specifically targeted at streaming workflows using TTML.

RFC 8760 The Session Initiation Protocol (SIP) Digest Access Authentication Scheme

Authors: R. Shekh-Yusef.

Date: March 2020

Formats: txt html pdf xml json

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8760

This document updates RFC 3261 by modifying the Digest AccessAuthentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g., SHA-256 andSHA-512/256, to replace the obsolete MD5 algorithm.

RFC 8761 Video Codec Requirements and Evaluation Methodology

Authors: A. Filippov, A. Norkin, J.R. Alvarez.

Date: April 2020

Formats: txt pdf xml html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8761

This document provides requirements for a video codec designed mainly for use over the Internet. In addition, this document describes an evaluation methodology for measuring the compression efficiency to determine whether or not the stated requirements have been fulfilled.

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 8763 Deployment Considerations for Information-Centric Networking (ICN)

Authors: A. Rahman, D. Trossen, D. Kutscher, R. Ravindran.

Date: April 2020

Formats: txt json xml html pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8763

Information-Centric Networking (ICN) is now reaching technological maturity after many years of fundamental research and experimentation. This document provides a number of deployment considerations in the interest of helping the ICN community move forward to the next step of live deployments. First, the major deployment configurations for ICN are described, including the key overlay and underlay approaches. Then, proposed deployment migration paths are outlined to address major practical issues, such as network and application migration. Next, selected ICN trial experiences are summarized. Finally, protocol areas that require further standardization are identified to facilitate future interoperable ICN deployments. This document is a product of the Information-CentricNetworking Research Group (ICNRG).

RFC 8764 Apple's DNS Long-Lived Queries Protocol

Authors: S. Cheshire, M. Krochmal.

Date: June 2020

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8764

Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending theDNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From2005 onwards, LLQ was implemented in Apple products including Mac OSX, Bonjour for Windows, and AirPort wireless base stations. In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765,"DNS Push Notifications", which builds on experience gained with theLLQ protocol to create a superior replacement.
The existing LLQ protocol deployed and used from 2005 to 2020 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS PushNotifications.

RFC 8765 DNS Push Notifications

Authors: T. Pusateri, S. Cheshire.

Date: June 2020

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8765

The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But, there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes toDNS records, called DNS Push Notifications.

RFC 8766 Discovery Proxy for Multicast DNS-Based Service Discovery

Authors: S. Cheshire.

Date: June 2020

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8766

This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link.

RFC 8767 Serving Stale Data to Improve DNS Resiliency

Authors: D. Lawrence, W. Kumari, P. Sood.

Date: March 2020

Formats: txt pdf xml json html

Updates: RFC 1034, RFC 1035, RFC 2181

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8767

This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days.

RFC 8768 Constrained Application Protocol (CoAP) Hop-Limit Option

Authors: M. Boucadair, T. Reddy.K, J. Shallow.

Date: March 2020

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8768

The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option.

RFC 8769 Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR)

Authors: J. Schaad.

Date: March 2020

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8769

Concise Binary Object Representation (CBOR) is becoming a widely used method of doing content encoding. The Cryptographic Message Syntax(CMS) is still a widely used method of doing message-based security.This document defines a set of content types for CMS that hold CBOR content.

RFC 8770 Host Router Support for OSPFv2

Authors: K. Patel, P. Pillay-Esnault, M. Bhardwaj, S. Bayraktar.

Date: April 2020

Formats: txt xml pdf html json

Updates: RFC 6987

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8770

The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit called the Host-bit(H-bit). This bit enables a router to advertise that it is a non- transit router. This document also describes the changes needed to support the H-bit in the domain. In addition, this document updatesRFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA)Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively.

RFC 8771 The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO)

Authors: A. Mayrhofer, J. Hague.

Date: 1 April 2020

Formats: txt html xml pdf json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8771

Domain Names were designed for humans, IP addresses were not. But more than 30 years after the introduction of the DNS, a minority of mankind persists in invading the realm of machine-to-machine communication by reading, writing, misspelling, memorizing, permuting, and confusing IP addresses. This memo describes theInternationalized Deliberately Unreadable Network NOtation("I-DUNNO"), a notation designed to replace current textual representations of IP addresses with something that is not only more concise but will also discourage this small, but obviously important, subset of human activity.

RFC 8772 The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP)

Authors: S. Hu, D. Eastlake, F. Qin, T. Chua, D. Huang.

Date: May 2020

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8772

A Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router and the aggregation point for subscriber traffic. Control and User Plane Separation (CUPS) for such a BNG improves flexibility and scalability but requires various communication between the User Plane (UP) and the Control Plane (CP).China Mobile, Huawei Technologies, and ZTE have developed a simpleCUPS control channel protocol to support such communication: theSimple Control and User Plane Separation Protocol (S-CUSP). S-CUSP is defined in this document.
This document is not an IETF standard and does not have IETF consensus. S-CUSP is presented here to make its specification conveniently available to the Internet community to enable diagnosis and interoperability.

RFC 8773 TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key

Authors: R. Housley.

Date: March 2020

Formats: txt json html pdf xml

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8773

This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK).

RFC 8774 The Quantum Bug

Authors: M. Welzl.

Date: 1 April 2020

Formats: txt html pdf json xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8774

The age of quantum networking is upon us, and with it comes"entanglement": a procedure in which a state (i.e., a bit) can be transferred instantly, with no measurable delay between peers. This will lead to a perceived round-trip time of zero seconds on someInternet paths, a capability which was not predicted and so not included as a possibility in many protocol specifications. Worse than the millennium bug, this unexpected value is bound to cause serious Internet failures unless the specifications are fixed in time.

RFC 8775 PIM Designated Router Load Balancing

Authors: Y. Cai, H. Ou, S. Vallepalli, M. Mishra, S. Venaas, A. Green.

Date: April 2020

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8775

On a multi-access network, one of the PIM-SM (PIM Sparse Mode) routers is elected as a Designated Router. One of the responsibilities of the Designated Router is to track local multicast listeners and forward data to these listeners if the group is operating in PIM-SM. This document specifies a modification to thePIM-SM protocol that allows more than one of the PIM-SM routers to take on this responsibility so that the forwarding load can be distributed among multiple routers.

RFC 8776 Common YANG Data Types for Traffic Engineering

Authors: T. Saad, R. Gandhi, X. Liu, V. Beeram, I. Bryskin.

Date: June 2020

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8776

This document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model TrafficEngineering (TE) configuration and state capabilities.

RFC 8777 DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery

Authors: J. Holland.

Date: April 2020

Formats: txt xml pdf json html

Updates: RFC 7450

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8777

This document updates RFC 7450, "Automatic Multicast Tunneling" (orAMT), by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Other extensions and clarifications to the relay discovery process are also defined.

RFC 8778 Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)

Authors: R. Housley.

Date: April 2020

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8778

This document specifies the conventions for using the HierarchicalSignature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption(COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.

RFC 8779 Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS

Authors: C. Margaria, Ed., O. Gonzalez de Dios, Ed., F. Zhang, Ed..

Date: July 2020

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8779

A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC7025.
This memo provides extensions to the Path Computation ElementCommunication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements.

RFC 8780 The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA)

Authors: Y. Lee, Ed., R. Casellas, Ed..

Date: July 2020

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8780

This document provides Path Computation Element CommunicationProtocol (PCEP) extensions for the support of Routing and WavelengthAssignment (RWA) in Wavelength Switched Optical Networks (WSONs).Path provisioning in WSONs requires an RWA process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical path computation.

RFC 8781 Discovering PREF64 in Router Advertisements

Authors: L. Colitti, J. Linkova.

Date: April 2020

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8781

This document specifies a Neighbor Discovery option to be used inRouter Advertisements (RAs) to communicate prefixes of NetworkAddress and Protocol Translation from IPv6 clients to IPv4 servers(NAT64) to hosts.

RFC 8782 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification

Authors: T. Reddy.K, Ed., M. Boucadair, Ed., P. Patil, A. Mortensen, N. Teague.

Date: May 2020

Formats: txt pdf xml json html

Obsoleted by: RFC 9132

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8782

This document specifies the Distributed Denial-of-Service Open ThreatSignaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.

RFC 8783 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification

Authors: M. Boucadair, Ed., T. Reddy.K, Ed..

Date: May 2020

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8783

The document specifies a Distributed Denial-of-Service Open ThreatSignaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.
This is a companion document to "Distributed Denial-of-Service OpenThreat Signaling (DOTS) Signal Channel Specification" (RFC 8782).

RFC 8784 Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security

Authors: S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov.

Date: June 2020

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8784

The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet KeyExchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available.It is anticipated that IKEv2 will be extended to support quantum- secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.

RFC 8785 JSON Canonicalization Scheme (JCS)

Authors: A. Rundgren, B. Jordan, S. Erdtman.

Date: June 2020

Formats: txt pdf xml html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8785

Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results.
This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation ofJSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to theInternet JSON (I-JSON) subset, and by using deterministic property sorting.

RFC 8786 Updated Rules for Processing Stateful PCE Request Parameters Flags

Authors: A. Farrel.

Date: May 2020

Formats: txt json html xml pdf

Updates: RFC 8231

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8786

Extensions to the Path Computation Element Communication Protocol(PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCERequest Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages.
This document updates RFC 8231 by defining the correct behaviors.

RFC 8787 Location Source Parameter for the SIP Geolocation Header Field

Authors: J. Winterbottom, R. Jesske, B. Chatras, A. Hutton.

Date: May 2020

Formats: txt json xml pdf html

Updates: RFC 6442

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8787

There are some circumstances where a Geolocation header field may contain more than one locationValue. Knowing the identity of the node adding the locationValue allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the locationValues. This document defines the "loc-src" parameter so that the entity adding the locationValue to theGeolocation header field can identify itself using its hostname.This document updates RFC 6442.

RFC 8788 Eligibility for the 2020-2021 Nominating Committee

Authors: B. Leiba.

Date: May 2020

Formats: txt html json xml pdf

Obsoleted by: RFC 9389

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8788

The 2020-2021 Nominating Committee (NomCom) is to be formed between the IETF 107 and IETF 108 meetings, and the issue of eligibility of who can serve on that NomCom needs clarification. This document provides a one-time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in- person IETF 107 meeting. This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108; it does not set a precedent to be applied in the future.

RFC 8789 IETF Stream Documents Require IETF Rough Consensus

Authors: J. Halpern, Ed., E. Rescorla, Ed..

Date: June 2020

Formats: txt html xml pdf json

Updates: RFC 2026

Also: BCP 0009

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8789

This document requires that the IETF never publish any IETF StreamRFCs without IETF rough consensus. This updates RFC 2026.

RFC 8790 FETCH and PATCH with Sensor Measurement Lists (SenML)

Authors: A. Keränen, M. Mohajer.

Date: June 2020

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8790

The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The Constrained Application Protocol(CoAP) FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented using the SenML data model.

RFC 8791 YANG Data Structure Extensions

Authors: A. Bierman, M. Björklund, K. Watsen.

Date: June 2020

Formats: txt html pdf xml json

Updates: RFC 8340

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8791

This document describes YANG mechanisms for defining abstract data structures with YANG.

RFC 8792 Handling Long Lines in Content of Internet-Drafts and RFCs

Authors: K. Watsen, E. Auerswald, A. Farrel, Q. Wu.

Date: June 2020

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8792

This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.

RFC 8793 Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology

Authors: B. Wissingh, C. Wood, A. Afanasyev, L. Zhang, D. Oran, C. Tschudin.

Date: June 2020

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8793

Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named DataNetworking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are otherICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG).

RFC 8794 Extensible Binary Meta Language

Authors: S. Lhomme, D. Rice, M. Bunkus.

Date: July 2020

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8794

This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage.EBML is designed as a binary equivalent to XML and uses a storage- efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines howEBML Schemas are created to convey the semantics of an EBML Document.

RFC 8795 YANG Data Model for Traffic Engineering (TE) Topologies

Authors: X. Liu, I. Bryskin, V. Beeram, T. Saad, H. Shah, O. Gonzalez de Dios.

Date: August 2020

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8795

This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment.

RFC 8796 RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels

Authors: M. Taillon, T. Saad, Ed., R. Gandhi, A. Deshmukh, M. Jork, V. Beeram.

Date: July 2020

Formats: txt json pdf xml html

Updates: RFC 4090

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8796

This document updates RFC 4090 for the Resource Reservation Protocol(RSVP) Traffic Engineering (TE) procedures defined for facility backup protection. The updates include extensions that reduce the amount of signaling and processing that occurs during Fast Reroute(FRR); as a result, scalability when undergoing FRR convergence after a link or node failure is improved. These extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and theMerge Point (MP) nodes to be independent of the number of protectedLabel Switched Paths (LSPs) traversing between them when facility bypass FRR protection is used. The signaling extensions are fully backwards compatible with nodes that do not support them.

RFC 8797 Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1

Authors: C. Lever.

Date: June 2020

Formats: txt json pdf html xml

Updates: RFC 8166

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8797

This document specifies the format of Remote Direct Memory Access -Connection Manager (RDMA-CM) Private Data exchanged between RPC-over-RDMA version 1 peers as part of establishing a connection. The addition of the Private Data payload specified in this document is an optional extension that does not alter the RPC-over-RDMA version 1 protocol. This document updates RFC 8166.

RFC 8798 Additional Units for Sensor Measurement Lists (SenML)

Authors: C. Bormann.

Date: June 2020

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8798

The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry, as they are derived by linear transformation from units already in that registry.

RFC 8799 Limited Domains and Internet Protocols

Authors: B. Carpenter, B. Liu.

Date: July 2020

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8799

There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes.
This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.

RFC 8800 Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling

Authors: S. Litkowski, S. Sivabalan, C. Barth, M. Negi.

Date: July 2020

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8800

This document introduces a simple mechanism to associate a group ofLabel Switched Paths (LSPs) via an extension to the Path ComputationElement Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a PathComputation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that theLSPs in the same group need to be disjoint from each other.

RFC 8801 Discovering Provisioning Domain Names and Data

Authors: P. Pfister, É. Vyncke, T. Pauly, D. Schinazi, W. Shao.

Date: July 2020

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8801

Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider.
This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate betweenPvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS.

RFC 8802 The Quality for Service (Q4S) Protocol

Authors: J.J. Aranda, M. Cortes, J. Salvachúa, M. Narganes, I. Martínez-Sarriegui.

Date: July 2020

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8802

This memo describes an application-level protocol for the communication of end-to-end QoS compliance information based on theHyperText Transfer Protocol (HTTP) and the Session DescriptionProtocol (SDP). The Quality for Service (Q4S) protocol provides a mechanism to negotiate and monitor latency, jitter, bandwidth, and packet loss, and to alert whenever one of the negotiated conditions is violated.
Implementation details on the actions to be triggered upon reception/ detection of QoS alerts exchanged by the protocol are out of scope of this document; it is either application dependent (e.g., act to increase quality or reduce bit-rate) or network dependent (e.g., change connection's quality profile).
This protocol specification is the product of research conducted over a number of years; it is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus.

RFC 8803 0-RTT TCP Convert Protocol

Authors: O. Bonaventure, Ed., M. Boucadair, Ed., S. Gundavelli, S. Seo, B. Hesmans.

Date: July 2020

Formats: txt pdf xml html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8803

This document specifies an application proxy, called TransportConverter, to assist the deployment of TCP extensions such asMultipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert).
This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever).
This specification assumes an explicit model, where the TransportConverter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the ConvertProtocol applies for Multipath TCP.

RFC 8804 Content Delivery Network Interconnection (CDNI) Request Routing Extensions

Authors: O. Finkelman, S. Mishra.

Date: September 2020

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8804

Open Caching architecture is a use case of Content Delivery NetworkInterconnection (CDNI) in which the commercial Content DeliveryNetwork (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document defines extensions to the CDNI Metadata Interface (MI) and the Footprint &Capabilities Advertisement interface (FCI). These extensions are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general.

RFC 8805 A Format for Self-Published IP Geolocation Feeds

Authors: E. Kline, K. Duleba, Z. Szamonek, S. Moser, W. Kumari.

Date: August 2020

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8805

This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location.
Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds.
This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated.

RFC 8806 Running a Root Server Local to a Resolver

Authors: W. Kumari, P. Hoffman.

Date: June 2020

Formats: txt html xml pdf json

Obsoletes: RFC 7706

Status: INFORMATIONAL

DOI: 10.17487/RFC 8806

Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round- trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator.
This document obsoletes RFC 7706.

RFC 8807 Login Security Extension for the Extensible Provisioning Protocol (EPP)

Authors: J. Gould, M. Pozun.

Date: August 2020

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8807

The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XMLSchema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response.

RFC 8808 A YANG Data Model for Factory Default Settings

Authors: Q. Wu, B. Lengyel, Y. Niu.

Date: August 2020

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8808

This document defines a YANG data model with the "factory-reset" RPC to allow clients to reset a server back to its factory default condition. It also defines an optional "factory-default" datastore to allow clients to read the factory default configuration for the device.
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342.

RFC 8809 Registries for Web Authentication (WebAuthn)

Authors: J. Hodges, G. Mandyam, M. Jones.

Date: August 2020

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8809

This specification defines IANA registries for W3C Web Authentication(WebAuthn) attestation statement format identifiers and extension identifiers.

RFC 8810 Revision to Capability Codes Registration Procedures

Authors: J. Scudder.

Date: August 2020

Formats: txt json pdf xml html

Updates: RFC 5492

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8810

This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Private Use" is divided into three new ranges:"First Come First Served", "Experimental Use", and "Reserved".

RFC 8811 DDoS Open Threat Signaling (DOTS) Architecture

Authors: A. Mortensen, Ed., T. Reddy.K, Ed., F. Andreasen, N. Teague, R. Compton.

Date: August 2020

Formats: txt json html pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8811

This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open ThreatSignaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.

RFC 8812 CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms

Authors: M. Jones.

Date: August 2020

Formats: txt xml html pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8812

The W3C Web Authentication (WebAuthn) specification and the FIDOAlliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers.This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA"JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.

RFC 8813 Clarifications for Elliptic Curve Cryptography Subject Public Key Information

Authors: T. Ito, S. Turner.

Date: August 2020

Formats: txt xml html pdf json

Updates: RFC 5480

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8813

This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography.

RFC 8814 Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State

Authors: J. Tantsura, U. Chunduri, K. Talaulikar, G. Mirsky, N. Triantafillis.

Date: August 2020

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8814

This document defines a way for a Border Gateway Protocol - LinkState (BGP-LS) speaker to advertise multiple types of supportedMaximum SID Depths (MSDs) at node and/or link granularity.
Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network.

RFC 8815 Deprecating Any-Source Multicast (ASM) for Interdomain Multicast

Authors: M. Abrahamsson, T. Chown, L. Giuliano, T. Eckert.

Date: August 2020

Formats: txt xml pdf json html

Also: BCP 0229

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8815

This document recommends deprecation of the use of Any-SourceMulticast (ASM) for interdomain multicast. It recommends the use ofSource-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).

RFC 8816 Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases

Authors: E. Rescorla, J. Peterson.

Date: February 2021

Formats: txt html json pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8816

The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality.

RFC 8817 RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec

Authors: V. Demjanenko, J. Punaro, D. Satterlee.

Date: August 2020

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8817

This document describes the RTP payload format for the TacticalSecure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder. TSVCIS is a scalable narrowband voice coder supporting varying encoder data rates and fallbacks. It is implemented as an augmentation to the Mixed Excitation Linear Prediction Enhanced(MELPe) speech coder by conveying additional speech coder parameters to enhance voice quality. TSVCIS augmented speech data is processed in conjunction with its temporally matched Mixed Excitation LinearPrediction (MELP) 2400 speech data. The RTP packetization of TSVCIS and MELPe speech coder data is described in detail.

RFC 8818 Distributed Mobility Anchoring

Authors: H. Chan, Ed., X. Wei, J. Lee, S. Jeon, CJ. Bernardos, Ed..

Date: October 2020

Formats: txt json pdf html xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8818

This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support, depending on the network's needs. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or restarted using an IP address configured from the new IP prefix anchored to the new network. If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility. This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network.

RFC 8819 YANG Module Tags

Authors: C. Hopps, L. Berger, D. Bogdanovic.

Date: January 2021

Formats: txt json html pdf xml

Updates: RFC 8407

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8819

This document provides for the association of tags with YANG modules.The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading, and writing modules tags is provided. Tags may be registered and assigned during module definition, assigned by implementations, or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC 8407.

RFC 8820 URI Design and Ownership

Authors: M. Nottingham.

Date: June 2020

Formats: txt xml pdf json html

Obsoletes: RFC 7320

Updates: RFC 3986

Also: BCP 0190

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8820

Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic.
This document provides guidance on the specification of URI substructure in standards.
This document obsoletes RFC 7320 and updates RFC 3986.

RFC 8821 PCE-Based Traffic Engineering (TE) in Native IP Networks

Authors: A. Wang, B. Khasanov, Q. Zhao, H. Chen.

Date: April 2021

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8821

This document defines an architecture for providing traffic engineering in a native IP network using multiple BGP sessions and aPath Computation Element (PCE)-based central control mechanism. It defines the Centralized Control Dynamic Routing (CCDR) procedures and identifies needed extensions for the Path Computation ElementCommunication Protocol (PCEP).

RFC 8822 5G Wireless Wireline Convergence User Plane Encapsulation (5WE)

Authors: D. Allan, Ed., D. Eastlake, D. Woolley.

Date: April 2021

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8822

As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF). The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within a VLAN-delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding. It achieves this by specific points of similarity with the Point-to-Point Protocol over Ethernet (PPPoE) data packet encapsulation (RFC 2516).

RFC 8823 Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates

Authors: A. Melnikov.

Date: April 2021

Formats: txt html pdf json xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8823

This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.

RFC 8824 Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)

Authors: A. Minaburo, L. Toutain, R. Andreasen.

Date: June 2021

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8824

This document defines how to compress Constrained ApplicationProtocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.

RFC 8825 Overview: Real-Time Protocols for Browser-Based Applications

Authors: H. Alvestrand.

Date: January 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8825

This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".
It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track.
This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC).

RFC 8826 Security Considerations for WebRTC

Authors: E. Rescorla.

Date: January 2021

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8826

WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model.

RFC 8827 WebRTC Security Architecture

Authors: E. Rescorla.

Date: January 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8827

This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".

RFC 8828 WebRTC IP Address Handling Requirements

Authors: J. Uberti, G. Shieh.

Date: January 2021

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8828

This document provides information and requirements for how IP addresses should be handled by Web Real-Time Communication (WebRTC) implementations.

RFC 8829 JavaScript Session Establishment Protocol (JSEP)

Authors: J. Uberti, C. Jennings, E. Rescorla, Ed..

Date: January 2021

Formats: txt xml json pdf html

Obsoleted by: RFC 9429

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8829

This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols.

RFC 8830 WebRTC MediaStream Identification in the Session Description Protocol

Authors: H. Alvestrand.

Date: January 2021

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8830

This document specifies a Session Description Protocol (SDP) grouping mechanism for RTP media streams that can be used to specify relations between media streams.
This mechanism is used to signal the association between the SDP concept of "media description" and the Web Real-Time Communication(WebRTC) concept of MediaStream/MediaStreamTrack using SDP signaling.

RFC 8831 WebRTC Data Channels

Authors: R. Jesup, S. Loreto, M. Tüxen.

Date: January 2021

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8831

The WebRTC framework specifies protocol support for direct, interactive, rich communication using audio, video, and data between two peers' web browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control TransmissionProtocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer.

RFC 8832 WebRTC Data Channel Establishment Protocol

Authors: R. Jesup, S. Loreto, M. Tüxen.

Date: January 2021

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8832

The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two-way handshake and allows sending of user data without waiting for the handshake to complete.

RFC 8833 Application-Layer Protocol Negotiation (ALPN) for WebRTC

Authors: M. Thomson.

Date: January 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8833

This document specifies two Application-Layer Protocol Negotiation(ALPN) labels for use with Web Real-Time Communication (WebRTC). The"webrtc" label identifies regular WebRTC: a DTLS session that is used to establish keys for the Secure Real-time Transport Protocol (SRTP) or to establish data channels using the Stream Control TransmissionProtocol (SCTP) over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications.

RFC 8834 Media Transport and Use of RTP in WebRTC

Authors: C. Perkins, M. Westerlund, J. Ott.

Date: January 2021

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8834

The framework for Web Real-Time Communication (WebRTC) provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web browsers.This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context and gives requirements for which RTP features, profiles, and extensions need to be supported.

RFC 8835 Transports for WebRTC

Authors: H. Alvestrand.

Date: January 2021

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8835

This document describes the data transport protocols used by WebReal-Time Communication (WebRTC), including the protocols used for interaction with intermediate boxes such as firewalls, relays, andNAT boxes.

RFC 8836 Congestion Control Requirements for Interactive Real-Time Media

Authors: R. Jesup, Z. Sarker, Ed..

Date: January 2021

Formats: txt pdf xml html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8836

Congestion control is needed for all data transported across theInternet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled.
This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for a real-time media congestion avoidance technique.

RFC 8837 Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS

Authors: P. Jones, S. Dhesikan, C. Jennings, D. Druta.

Date: January 2021

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8837

Networks can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of Web Real-TimeCommunication (WebRTC) traffic.

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 8839 Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)

Authors: M. Petit-Huguenin, S. Nandakumar, C. Holmberg, A. Keränen, R. Shpount.

Date: January 2021

Formats: txt json pdf xml html

Obsoletes: RFC 5245, RFC 6336

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8839

This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive ConnectivityEstablishment (ICE) between the agents.
This document obsoletes RFCs 5245 and 6336.

RFC 8840 A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)

Authors: E. Ivov, T. Stach, E. Marocco, C. Holmberg.

Date: January 2021

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8840

The Interactive Connectivity Establishment (ICE) protocol describes aNetwork Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.
This document defines usage semantics for Trickle ICE with theSession Initiation Protocol (SIP). The document also defines a newSIP Info Package to support this usage together with the corresponding media type. Additionally, a new Session DescriptionProtocol (SDP) "end-of-candidates" attribute and a new SIP option tag"trickle-ice" are defined.

RFC 8841 Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport

Authors: C. Holmberg, R. Shpount, S. Loreto, G. Camarillo.

Date: January 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8841

The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. RFC8261 specifies how SCTP can be used on top of the Datagram TransportLayer Security (DTLS) protocol, which is referred to as SCTP-over-DTLS.
This specification defines the following new Session DescriptionProtocol (SDP) protocol identifiers (proto values): "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". This specification also specifies how to use the new proto values with the SDP offer/answer mechanism for negotiating SCTP-over-DTLS associations.

RFC 8842 Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)

Authors: C. Holmberg, R. Shpount.

Date: January 2021

Formats: txt pdf xml json html

Updates: RFC 5763, RFC 7345

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8842

This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing a DatagramTransport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFCs 5763 and 7345 by replacing common SDP offer/answer procedures with a reference to this specification.
This document defines a new SDP media-level attribute, "tls-id".
This document also defines how the "tls-id" attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFCs 4145 and 8122.

RFC 8843 Negotiating Media Multiplexing Using the Session Description Protocol (SDP)

Authors: C. Holmberg, H. Alvestrand, C. Jennings.

Date: January 2021

Formats: txt pdf json xml html

Obsoleted by: RFC 9143

Updates: RFC 3264, RFC 5888, RFC 7941

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8843

This specification defines a new Session Description Protocol (SDP)Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group.
This specification defines a new RTP Control Protocol (RTCP) SourceDescription (SDES) item and a new RTP header extension.
This specification updates RFCs 3264, 5888, and 7941.

RFC 8844 Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)

Authors: M. Thomson, E. Rescorla.

Date: January 2021

Formats: txt pdf xml html json

Updates: RFC 8122

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8844

This document describes unknown key-share attacks on the use ofDatagram Transport Layer Security for the Secure Real-Time TransportProtocol (DTLS-SRTP). Similar attacks are described on the use ofDTLS-SRTP with the identity bindings used in Web Real-TimeCommunications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy.

RFC 8845 Framework for Telepresence Multi-Streams

Authors: M. Duckworth, Ed., A. Pepperell, S. Wenger.

Date: January 2021

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8845

This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting, and rendering the media streams. This protocol is used in addition to SIP signaling and Session DescriptionProtocol (SDP) negotiation for setting up a telepresence session.

RFC 8846 An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model

Authors: R. Presta, S P. Romano.

Date: January 2021

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8846

This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "Controlling MultipleStreams for Telepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario.

RFC 8847 Protocol for Controlling Multiple Streams for Telepresence (CLUE)

Authors: R. Presta, S P. Romano.

Date: January 2021

Formats: txt json xml html pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8847

The Controlling Multiple Streams for Telepresence (CLUE) protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within theIETF CLUE Working Group. A companion document, RFC 8848, delves intoCLUE signaling details as well as the SIP / Session DescriptionProtocol (SDP) session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP-over-DTLS transport. ("SCTP" stands for "Stream Control TransmissionProtocol".) Message details, together with the behavior of CLUEParticipants acting as Media Providers and/or Media Consumers, are herein discussed.

RFC 8848 Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)

Authors: R. Hanton, P. Kyzivat, L. Xiao, C. Groves.

Date: January 2021

Formats: txt html json xml pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8848

This document is about Controlling Multiple Streams for Telepresence(CLUE) signaling. It specifies how the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms, such as SIP and the SessionDescription Protocol (SDP), to produce a telepresence call.

RFC 8849 Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures

Authors: R. Even, J. Lennox.

Date: January 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8849

This document describes how the Real-time Transport Protocol (RTP) is used in the context of the Controlling Multiple Streams forTelepresence (CLUE) protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams, as defined in theSession Description Protocol (SDP), to CLUE Media Captures and defines a new RTP header extension (CaptureID).

RFC 8850 Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel

Authors: C. Holmberg.

Date: January 2021

Formats: txt html pdf json xml

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8850

This document defines how to use the WebRTC data channel mechanism to realize a data channel, referred to as a Controlling Multiple Streams for Telepresence (CLUE) data channel, for transporting CLUE protocol messages between two CLUE entities.

RFC 8851 RTP Payload Format Restrictions

Authors: A.B. Roach, Ed..

Date: January 2021

Formats: txt html pdf xml json

Updates: RFC 4855

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8851

In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol(SDP). This framework defines a new "rid" ("restriction identifier")SDP attribute to unambiguously identify the RTP streams within an RTP session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular payload types.
This specification updates RFC 4855 to give additional guidance on choice of Format Parameter (fmtp) names and their relation to the restrictions defined by this document.

RFC 8852 RTP Stream Identifier Source Description (SDES)

Authors: A.B. Roach, S. Nandakumar, P. Thatcher.

Date: January 2021

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8852

This document defines and registers two new Real-time TransportControl Protocol (RTCP) Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification ofRTP streams. The other, RepairedRtpStreamId, can be used to identify which stream is to be repaired using a redundancy RTP stream.

RFC 8853 Using Simulcast in Session Description Protocol (SDP) and RTP Sessions

Authors: B. Burman, M. Westerlund, S. Nandakumar, M. Zanaty.

Date: January 2021

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8853

In some application scenarios, it may be desirable to send multiple differently encoded versions of the same media source in differentRTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in the SessionDescription Protocol (SDP). The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source and makes an extension to SDP to indicate that those RTP streams are different simulcast formats of that media source. TheSDP extension consists of a new media-level SDP attribute that expresses capability to send and/or receive simulcast RTP streams.

RFC 8854 WebRTC Forward Error Correction Requirements

Authors: J. Uberti.

Date: January 2021

Formats: txt xml html pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8854

This document provides information and requirements for the use ofForward Error Correction (FEC) by WebRTC implementations.

RFC 8855 The Binary Floor Control Protocol (BFCP)

Authors: G. Camarillo, K. Drage, T. Kristensen, J. Ott, C. Eckel.

Date: January 2021

Formats: txt xml html pdf json

Obsoletes: RFC 4582

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8855

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.
This document obsoletes RFC 4582.

RFC 8856 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams

Authors: G. Camarillo, T. Kristensen, C. Holmberg.

Date: January 2021

Formats: txt json html pdf xml

Obsoletes: RFC 4583

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8856

This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing Binary FloorControl Protocol (BFCP) streams.
This document obsoletes RFC 4583.

RFC 8857 The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)

Authors: V. Pascual, A. Román, S. Cazeaux, G. Salgueiro, R. Ravindranath.

Date: January 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8857

The WebSocket protocol enables two-way real-time communication between clients and servers. This document specifies the use ofBinary Floor Control Protocol (BFCP) as a new WebSocket subprotocol enabling a reliable transport mechanism between BFCP entities in new scenarios.

RFC 8858 Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)

Authors: C. Holmberg.

Date: January 2021

Formats: txt html json pdf xml

Updates: RFC 5761

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8858

This document defines a new Session Description Protocol (SDP) media- level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP and RTP Control Protocol (RTCP) multiplexing. The document also updates RFC 5761 by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports.

RFC 8859 A Framework for Session Description Protocol (SDP) Attributes When Multiplexing

Authors: S. Nandakumar.

Date: January 2021

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8859

The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session DescriptionProtocol (SDP) attributes when SDP is used to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple media descriptions.
This specification also categorizes the existing SDP attributes based on the framework described herein.

RFC 8860 Sending Multiple Types of Media in a Single RTP Session

Authors: M. Westerlund, C. Perkins, J. Lennox.

Date: January 2021

Formats: txt xml pdf html json

Updates: RFC 3550, RFC 3551

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8860

This document specifies how an RTP session can contain RTP streams with media from multiple media types such as audio, video, and text.This has been restricted by the RTP specifications (RFCs 3550 and3551), and thus this document updates RFCs 3550 and 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session.

RFC 8861 Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback

Authors: J. Lennox, M. Westerlund, Q. Wu, C. Perkins.

Date: January 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8861

RTP allows multiple RTP streams to be sent in a single session but requires each Synchronization Source (SSRC) to send RTP ControlProtocol (RTCP) reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases, most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a ReportingGroup extension to RTCP to reduce the reporting overhead in such scenarios.

RFC 8862 Best Practices for Securing RTP Media Signaled with SIP

Authors: J. Peterson, R. Barnes, R. Housley.

Date: January 2021

Formats: txt json pdf xml html

Also: BCP 0228

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8862

Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities.

RFC 8863 Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)

Authors: C. Holmberg, J. Uberti.

Date: January 2021

Formats: txt json html pdf xml

Updates: RFC 8445, RFC 8838

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8863

During the process of establishing peer-to-peer connectivity,Interactive Connectivity Establishment (ICE) agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur.
This document updates RFCs 8445 and 8838 by requiring that an ICE agent wait a minimum amount of time before declaring ICE failure, even if there are no candidate pairs left to check.

RFC 8864 Negotiation Data Channels Using the Session Description Protocol (SDP)

Authors: K. Drage, M. Makaraju, R. Ejzak, J. Marcon, R. Even, Ed..

Date: January 2021

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8864

Data channel setup can be done using either the in-band Data ChannelEstablishment Protocol (DCEP) or some out-of-band non-DCEP protocol.This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel.

RFC 8865 T.140 Real-Time Text Conversation over WebRTC Data Channels

Authors: C. Holmberg, G. Hellström.

Date: January 2021

Formats: txt html json pdf xml

Updates: RFC 8373

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8865

This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for real-time text using the ITU-T Protocol for multimedia application text conversation(Recommendation ITU-T T.140) and how the Session Description Protocol(SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as a T.140 data channel. This document updatesRFC 8373 to specify its use with WebRTC data channels.

RFC 8866 SDP: Session Description Protocol

Authors: A. Begen, P. Kyzivat, C. Perkins, M. Handley.

Date: January 2021

Formats: txt json xml pdf html

Obsoletes: RFC 4566

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8866

This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566.

RFC 8867 Test Cases for Evaluating Congestion Control for Interactive Real-Time Media

Authors: Z. Sarker, V. Singh, X. Zhu, M. Ramalho.

Date: January 2021

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8867

The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications. These applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms in a controlled environment.

RFC 8868 Evaluating Congestion Control for Interactive Real-Time Media

Authors: V. Singh, J. Ott, S. Holmer.

Date: January 2021

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8868

The Real-Time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media.

RFC 8869 Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks

Authors: Z. Sarker, X. Zhu, J. Fu.

Date: January 2021

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8869

The Real-time Transport Protocol (RTP) is a common transport choice for interactive multimedia communication applications. The performance of these applications typically depends on a well- functioning congestion control algorithm. To ensure a seamless and robust user experience, a well-designed RTP-based congestion control algorithm should work well across all access network types. This document describes test cases for evaluating performances of candidate congestion control algorithms over cellular and Wi-Fi networks.

RFC 8870 Encrypted Key Transport for DTLS and Secure RTP

Authors: C. Jennings, J. Mattsson, D. McGrew, D. Wing, F. Andreasen.

Date: January 2021

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8870

Encrypted Key Transport (EKT) is an extension to DTLS (DatagramTransport Layer Security) and the Secure Real-time Transport Protocol(SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints.

RFC 8871 A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)

Authors: P. Jones, D. Benham, C. Groves.

Date: January 2021

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8871

This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end to end within the context of a switched conferencing environment where MediaDistributors are not trusted with the end-to-end media encryption keys. The solution builds upon existing security mechanisms defined for the Real-time Transport Protocol (RTP).

RFC 8872 Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams

Authors: M. Westerlund, B. Burman, C. Perkins, H. Alvestrand, R. Even.

Date: January 2021

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8872

The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams.

RFC 8873 Message Session Relay Protocol (MSRP) over Data Channels

Authors: JM. Recio, Ed., C. Holmberg.

Date: January 2021

Formats: txt json xml html pdf

Updates: RFC 4975

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8873

This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for the MessageSession Relay Protocol (MSRP) and how the Session DescriptionProtocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as an MSRP data channel. Two network configurations are supported: the connection of two MSRP data channel endpoints; and a gateway configuration, which connects an MSRP data channel endpoint with an MSRP endpoint that uses either TCP or TLS.This document updates RFC 4975.

RFC 8874 Working Group GitHub Usage Guidance

Authors: M. Thomson, B. Stark.

Date: August 2020

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8874

This document provides a set of guidelines for working groups that choose to use GitHub for their work.

RFC 8875 Working Group GitHub Administration

Authors: A. Cooper, P. Hoffman.

Date: August 2020

Formats: txt html json xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8875

The use of GitHub in IETF working group processes is increasing.This document describes uses and conventions for working groups that are considering starting to use GitHub. It does not mandate any processes and does not require changes to the processes used by current and future working groups not using GitHub.

RFC 8876 Non-interactive Emergency Calls

Authors: B. Rosen, H. Schulzrinne, H. Tschofenig, R. Gellens.

Date: September 2020

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8876

Use of the Internet for emergency calling is described in RFC 6443,'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed, and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two-way interactive media such as voice or video or text. This document describes use of a SIPMESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document.

RFC 8877 Guidelines for Defining Packet Timestamps

Authors: T. Mizrahi, J. Fabini, A. Morton.

Date: September 2020

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8877

Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as"packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document.

RFC 8878 Zstandard Compression and the 'application/zstd' Media Type

Authors: Y. Collet, M. Kucherawy, Ed..

Date: February 2021

Formats: txt pdf html xml json

Obsoletes: RFC 8478

Status: INFORMATIONAL

DOI: 10.17487/RFC 8878

Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME.
Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.
This document replaces and obsoletes RFC 8478.

RFC 8879 TLS Certificate Compression

Authors: A. Ghedini, V. Vasiliev.

Date: December 2020

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8879

In TLS handshakes, certificate chains often take up the majority of the bytes transmitted.
This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.

RFC 8880 Special Use Domain Name 'ipv4only.arpa'

Authors: S. Cheshire, D. Schinazi.

Date: August 2020

Formats: txt html json pdf xml

Updates: RFC 7050

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8880

NAT64 (Network Address and Protocol Translation from IPv6 Clients toIPv4 Servers) allows client devices using IPv6 to communicate with servers that have only IPv4 connectivity.
The specification for how a client discovers its local network'sNAT64 prefix (RFC 7050) defines the special name 'ipv4only.arpa' for this purpose. However, in its Domain Name Reservation Considerations section (Section 8.1), that specification (RFC 7050) indicates that the name actually has no particularly special properties that would require special handling.
Consequently, despite the well-articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use DomainNames registry as a name with special properties.
This document updates RFC 7050. It describes the special treatment required and formally declares the special properties of the name.It also adds similar declarations for the corresponding reverse mapping names.

RFC 8881 Network File System (NFS) Version 4 Minor Version 1 Protocol

Authors: D. Noveck, Ed., C. Lever.

Date: August 2020

Formats: txt html pdf xml json

Obsoletes: RFC 5661

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8881

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 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol.
This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661.

RFC 8882 DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements

Authors: C. Huitema, D. Kaiser.

Date: September 2020

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8882

DNS-SD (DNS-based Service Discovery) normally discloses information about devices offering and requesting services. This information includes hostnames, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS-based Service Discovery at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy-respecting discovery service.

RFC 8883 ICMPv6 Errors for Discarding Packets Due to Processing Limits

Authors: T. Herbert.

Date: September 2020

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8883

Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits.When such packets are dropped, the sender receives no indication, so it cannot take action to address the cause of discarded packets.This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may use the information to diagnose packet loss and may modify what it sends in future packets to avoid subsequent packet discards.

RFC 8884 Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios

Authors: J. Seedorf, M. Arumaithurai, A. Tagami, K. Ramakrishnan, N. Blefari-Melazzi.

Date: October 2020

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8884

Information-Centric Networking (ICN) is a new paradigm where the network provides users with named content instead of communication channels between hosts. This document outlines some research directions for ICN with respect to applying ICN approaches for coping with natural or human-generated, large-scale disasters. This document is a product of the Information-Centric Networking ResearchGroup (ICNRG).

RFC 8885 Proxy Mobile IPv6 Extensions for Distributed Mobility Management

Authors: CJ. Bernardos, A. de la Oliva, F. Giust, JC. Zúñiga, A. Mourad.

Date: October 2020

Formats: txt html xml pdf json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8885

Distributed Mobility Management solutions allow networks to be set up in such a way that traffic is distributed optimally and centrally deployed anchors are not relied upon to provide IP mobility support.
There are many different approaches to address Distributed MobilityManagement -- for example, extending network-based mobility protocols(like Proxy Mobile IPv6) or client-based mobility protocols (likeMobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6, in which mobility sessions are anchored at the last IP hop router (called the mobility anchor and access router). The mobility anchor and access router is an enhanced access router that is also able to operate as a local mobility anchor or mobility access gateway on a per-prefix basis. The document focuses on the required extensions to effectively support the simultaneous anchoring several flows at different distributed gateways.

RFC 8886 Secure Device Install

Authors: W. Kumari, C. Doyle.

Date: September 2020

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8886

Deploying a new network device in a location where the operator has no staff of its own often requires that an employee physically travel to the location to perform the initial install and configuration, even in shared facilities with "remote-hands" (or similar) support.In many cases, this could be avoided if there were an easy way to transfer the initial configuration to a new device while still maintaining confidentiality of the configuration.
This document extends existing vendor proprietary auto-install to provide limited confidentiality to initial configuration during bootstrapping of the device.

RFC 8887 A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket

Authors: K. Murchison.

Date: August 2020

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8887

This document defines a binding for the JSON Meta ApplicationProtocol (JMAP) over a WebSocket transport layer. The WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP.

RFC 8888 RTP Control Protocol (RTCP) Feedback for Congestion Control

Authors: Z. Sarker, C. Perkins, V. Singh, M. Ramalho.

Date: January 2021

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8888

An effective RTP congestion control algorithm requires more fine- grained feedback on packet loss, timing, and Explicit CongestionNotification (ECN) marks than is provided by the standard RTP ControlProtocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets.This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control.

RFC 8889 Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring

Authors: G. Fioccola, Ed., M. Cociglio, A. Sapio, R. Sisto.

Date: August 2020

Formats: txt html pdf xml json

Obsoleted by: RFC 9342

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8889

The Alternate-Marking method, as presented in RFC 8321, can only be applied to point-to-point flows, because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document generalizes and expands this methodology to measure any kind of unicast flow whose packets can follow several different paths in the network -- in wider terms, a multipoint-to-multipoint network. For this reason, the technique here described is called "Multipoint Alternate Marking".

RFC 8890 The Internet is for End Users

Authors: M. Nottingham.

Date: August 2020

Formats: txt html xml json pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8890

This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this.

RFC 8891 GOST R 34.12-2015: Block Cipher "Magma"

Authors: V. Dolmatov, Ed., D. Baryshkov.

Date: September 2020

Formats: txt html xml pdf json

Updates: RFC 5830

Status: INFORMATIONAL

DOI: 10.17487/RFC 8891

In addition to a new cipher with a block length of n=128 bits(referred to as "Kuznyechik" and described in RFC 7801), RussianFederal standard GOST R 34.12-2015 includes an updated version of the block cipher with a block length of n=64 bits and key length of k=256 bits, which is also referred to as "Magma". The algorithm is an updated version of an older block cipher with a block length of n=64 bits described in GOST 28147-89 (RFC 5830). This document is intended to be a source of information about the updated version of the 64-bit cipher. It may facilitate the use of the block cipher inInternet applications by providing information for developers and users of the GOST 64-bit cipher with the revised version of the cipher for encryption and decryption.

RFC 8892 Guidelines and Registration Procedures for Interface Types and Tunnel Types

Authors: D. Thaler, D. Romascanu.

Date: August 2020

Formats: txt pdf xml json html

Updates: RFC 2863

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8892

This document provides guidelines and procedures for those who are defining, registering, or evaluating definitions of new interface types ("ifType" values) and tunnel types. The original definition of the IANA interface type registry predated the use of IANAConsiderations sections and YANG modules, so some confusion arose over time. Tunnel types were added later, with the same requirements and allocation policy as interface types. This document updates RFC2863 and provides updated guidance for these registries.

RFC 8893 Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export

Authors: R. Bush, R. Volk, J. Heitz.

Date: September 2020

Formats: txt json pdf xml html

Updates: RFC 6811

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8893

A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS.This document updates RFC 6811.

RFC 8894 Simple Certificate Enrolment Protocol

Authors: P. Gutmann.

Date: September 2020

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8894

This document specifies the Simple Certificate Enrolment Protocol(SCEP), a PKI protocol that leverages existing technology by usingCryptographic Message Syntax (CMS, formerly known as PKCS #7) andPKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.

RFC 8895 Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)

Authors: W. Roome, Y. Yang.

Date: November 2020

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8895

The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.

RFC 8896 Application-Layer Traffic Optimization (ALTO) Cost Calendar

Authors: S. Randriamasy, R. Yang, Q. Wu, L. Deng, N. Schwan.

Date: November 2020

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8896

This document is an extension to the base Application-Layer TrafficOptimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces the ALTOCost Calendar with which an ALTO Server exposes ALTO cost values inJSON arrays where each value corresponds to a given time interval.The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses.

RFC 8897 Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties

Authors: D. Ma, S. Kent.

Date: September 2020

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8897

This document provides a single reference point for requirements forRelying Party (RP) software for use in the Resource Public KeyInfrastructure (RPKI). It cites requirements that appear in severalRPKI RFCs, making it easier for implementers to become aware of these requirements. Over time, this RFC will be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein.

RFC 8898 Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)

Authors: R. Shekh-Yusef, C. Holmberg, V. Pascual.

Date: September 2020

Formats: txt html json xml pdf

Updates: RFC 3261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8898

This document defines the "Bearer" authentication scheme for theSession Initiation Protocol (SIP) and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core1.0. This document updates RFC 3261 to provide guidance on how a SIPUser Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields.

RFC 8899 Packetization Layer Path MTU Discovery for Datagram Transports

Authors: G. Fairhurst, T. Jones, M. Tüxen, I. Rüngeler, T. Völker.

Date: September 2020

Formats: txt html xml pdf json

Updates: RFC 4821, RFC 4960, RFC 6951, RFC 8085, RFC 8261

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8899

This document specifies Datagram Packetization Layer Path MTUDiscovery (DPLPMTUD). This is a robust method for Path MTU Discovery(PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP.
The document provides implementation notes for incorporating DatagramPMTUD into IETF datagram transports or applications that use datagram transports.
This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261.

RFC 8900 IP Fragmentation Considered Fragile

Authors: R. Bonica, F. Baker, G. Huston, R. Hinden, O. Troan, F. Gont.

Date: September 2020

Formats: txt html pdf json xml

Also: BCP 0230

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8900

This document describes IP fragmentation and explains how it introduces fragility to Internet communication.
This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators.

RFC 8901 Multi-Signer DNSSEC Models

Authors: S. Huque, P. Aras, J. Dickinson, J. Vcelak, D. Blacka.

Date: September 2020

Formats: txt html pdf json xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8901

Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describes these key-management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations.

RFC 8902 TLS Authentication Using Intelligent Transport System (ITS) Certificates

Authors: M. Msahli, Ed., N. Cam-Winget, Ed., W. Whyte, Ed., A. Serhrouchni, H. Labiod.

Date: September 2020

Formats: txt json xml pdf html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8902

The IEEE and ETSI have specified a type of end-entity certificate.This document defines an experimental change to TLS to support IEEE/ETSI certificate types to authenticate TLS entities.

RFC 8903 Use Cases for DDoS Open Threat Signaling

Authors: R. Dobbins, D. Migault, R. Moskowitz, N. Teague, L. Xia, K. Nishizuka.

Date: May 2021

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8903

The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoSMitigation solutions. This document presents sample use cases that describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what the typical information to be exchanged is.

RFC 8904 DNS Whitelist (DNSWL) Email Authentication Method Extension

Authors: A. Vesely.

Date: September 2020

Formats: txt xml html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8904

This document describes an email authentication method compliant withRFC 8601. The method consists of looking up the sender's IP address in a DNS whitelist. This document provides information in case the method is seen in the field, suggests a useful practice, and registers the relevant keywords.
This document does not consider blacklists.

RFC 8905 The 'payto' URI Scheme for Payments

Authors: F. Dold, C. Grothoff.

Date: October 2020

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8905

This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments.
A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications.

RFC 8906 A Common Operational Problem in DNS Servers: Failure to Communicate

Authors: M. Andrews, R. Bellis.

Date: September 2020

Formats: txt json pdf xml html

Also: BCP 0231

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8906

The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development.
This document identifies a number of common kinds of queries to which some servers either fail to respond or respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem.
The document does not look at the DNS data itself, just the structure of the responses.

RFC 8907 The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol

Authors: T. Dahm, A. Ota, D.C. Medway Gash, D. Carrel, L. Grant.

Date: September 2020

Formats: txt json html pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8907

This document describes the Terminal Access Controller Access-ControlSystem Plus (TACACS+) protocol, which is widely deployed today to provide Device Administration for routers, network access servers, and other networked computing devices via one or more centralized servers.

RFC 8908 Captive Portal API

Authors: T. Pauly, Ed., D. Thakore, Ed..

Date: September 2020

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8908

This document describes an HTTP API that allows clients to interact with a Captive Portal system. With this API, clients can discover how to get out of captivity and fetch state about their CaptivePortal sessions.

RFC 8909 Registry Data Escrow Specification

Authors: G. Lozano.

Date: November 2020

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8909

This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. The specification is designed to be independent of the underlying objects that are being escrowed, and therefore it could also be used for purposes other than domain name registries.

RFC 8910 Captive-Portal Identification in DHCP and Router Advertisements (RAs)

Authors: W. Kumari, E. Kline.

Date: September 2020

Formats: txt html xml pdf json

Obsoletes: RFC 7710

Updates: RFC 3679

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8910

In many environments offering short-term or temporary Internet access(such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions.
This document describes a DHCPv4 and DHCPv6 option and a RouterAdvertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document.
This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679.

RFC 8911 Registry for Performance Metrics

Authors: M. Bagnulo, B. Claise, P. Eardley, A. Morton, A. Akhter.

Date: November 2021

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8911

This document defines the format for the IANA Registry of PerformanceMetrics. This document also gives a set of guidelines for RegisteredPerformance Metric requesters and reviewers.

RFC 8912 Initial Performance Metrics Registry Entries

Authors: A. Morton, M. Bagnulo, P. Eardley, K. D'Souza.

Date: November 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8912

This memo defines the set of initial entries for the IANA Registry ofPerformance Metrics. The set includes UDP Round-Trip Latency andLoss, Packet Delay Variation, DNS Response Latency and Loss, UDPPoisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss,ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss.

RFC 8913 Two-Way Active Measurement Protocol (TWAMP) YANG Data Model

Authors: R. Civil, A. Morton, R. Rahman, M. Jethanandani, K. Pentikousis, Ed..

Date: November 2021

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8913

This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP).This document defines the TWAMP data model through Unified ModelingLanguage (UML) class diagrams and formally specifies it using theYANG data modeling language (RFC 7950). The data model is compliant with the Network Management Datastore Architecture (NMDA).

RFC 8914 Extended DNS Errors

Authors: W. Kumari, E. Hunt, R. Arends, W. Hardaker, D. Lawrence.

Date: October 2020

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8914

This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.

RFC 8915 Network Time Security for the Network Time Protocol

Authors: D. Franke, D. Sibold, K. Teichel, M. Dansarie, R. Sundblad.

Date: September 2020

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8915

This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).
NTS is structured as a suite of two loosely coupled sub-protocols.The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTSExtension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.

RFC 8916 A YANG Data Model for the Multicast Source Discovery Protocol (MSDP)

Authors: X. Liu, Z. Zhang, Ed., A. Peter, M. Sivakumar, F. Guo, P. McAllister.

Date: October 2020

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8916

This document defines a YANG data model for the configuration and management of Multicast Source Discovery Protocol (MSDP) protocol operations.

RFC 8917 The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag

Authors: R. Gellens, B. Rosen.

Date: October 2020

Formats: txt json xml html pdf

Updates: RFC 5222

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8917

This document adds the 'LoST-Validation' service tag to theStraightforward-Naming Authority PoinTeR (S-NAPTR) ApplicationService Tag IANA registry. This tag can appear in a Naming AuthorityPointer (NAPTR) Domain Name System (DNS) record to assist clients of the Location-to-Service Translation (LoST) Protocol in identifyingLoST servers designated for location validation. This tag and the information about its use update RFC 5222, which enables the explicit discovery of a server that supports location validation.

RFC 8918 Invalid TLV Handling in IS-IS

Authors: L. Ginsberg, P. Wells, T. Li, T. Przygienda, S. Hegde.

Date: September 2020

Formats: txt html xml json pdf

Updates: RFC 5305, RFC 6232

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8918

The key to the extensibility of the Intermediate System toIntermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol Data Unit(PDU) is received.
This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized.
This document updates RFCs 5305 and 6232.

RFC 8919 IS-IS Application-Specific Link Attributes

Authors: L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake.

Date: October 2020

Formats: txt html json xml pdf

Obsoleted by: RFC 9479

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8919

Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings.

RFC 8920 OSPF Application-Specific Link Attributes

Authors: P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake.

Date: October 2020

Formats: txt pdf xml html json

Obsoleted by: RFC 9492

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8920

Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements inOSPFv2 and OSPFv3 that address both of these shortcomings.

RFC 8921 Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP)

Authors: M. Boucadair, Ed., C. Jacquenet, D. Zhang, P. Georgatsos.

Date: October 2020

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8921

This document defines the Connectivity Provisioning NegotiationProtocol (CPNP), which is designed to facilitate the dynamic negotiation of service parameters.
CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, ContentDelivery Networks, etc.

RFC 8922 A Survey of the Interaction between Security Protocols and Transport Services

Authors: T. Enghardt, T. Pauly, C. Perkins, K. Rose, C. Wood.

Date: October 2020

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8922

This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog Transport Services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of theIETF, and those included represent a superset of features a TransportServices system may need to support.

RFC 8923 A Minimal Set of Transport Services for End Systems

Authors: M. Welzl, S. Gjessing.

Date: October 2020

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8923

This document recommends a minimal set of Transport Services offered by end systems and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303.

RFC 8924 Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework

Authors: S. Aldrin, C. Pignataro, Ed., N. Kumar, Ed., R. Krishnan, A. Ghanwani.

Date: October 2020

Formats: txt html json xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8924

This document provides a reference framework for Operations,Administration, and Maintenance (OAM) for Service Function Chaining(SFC).

RFC 8925 IPv6-Only Preferred Option for DHCPv4

Authors: L. Colitti, J. Linkova, M. Richardson, T. Mrugalski.

Date: October 2020

Formats: txt html xml pdf json

Updates: RFC 2563

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8925

This document specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. It also updatesRFC 2563 to specify DHCPv4 server behavior when the server receives aDHCPDISCOVER not containing the Auto-Configure option but containing the new option defined in this document.

RFC 8926 Geneve: Generic Network Virtualization Encapsulation

Authors: J. Gross, Ed., I. Ganga, Ed., T. Sridhar, Ed..

Date: November 2020

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8926

Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.

RFC 8927 JSON Type Definition

Authors: U. Carion.

Date: November 2020

Formats: txt pdf json xml html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8927

This document proposes a format, called JSON Type Definition (JTD), for describing the shape of JavaScript Object Notation (JSON) messages. Its main goals are to enable code generation from schemas as well as portable validation with standardized error indicators.To this end, JTD is intentionally limited to be no more expressive than the type systems of mainstream programming languages. This intentional limitation, as well as the decision to make JTD schemas be JSON documents, makes tooling atop of JTD easier to build.
This document does not have IETF consensus and is presented here to facilitate experimentation with the concept of JTD.

RFC 8928 Address-Protected Neighbor Discovery for Low-Power and Lossy Networks

Authors: P. Thubert, Ed., B. Sarikaya, M. Sethi, R. Struik.

Date: November 2020

Formats: txt pdf html xml json

Updates: RFC 8505

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8928

This document updates the IPv6 over Low-Power Wireless Personal AreaNetwork (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs6775 and 8505. The new extension is called Address-ProtectedNeighbor Discovery (AP-ND), and it protects the owner of an address against address theft and impersonation attacks in a Low-Power andLossy Network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto-ID), and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with theCrypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation.

RFC 8929 IPv6 Backbone Router

Authors: P. Thubert, Ed., C.E. Perkins, E. Levy-Abegnoli.

Date: November 2020

Formats: txt pdf xml html json

Updates: RFC 6775, RFC 8505

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8929

This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called"Backbone Routers". Backbone Routers are placed along the wireless edge of a backbone and federate multiple wireless links to form a single Multi-Link Subnet (MLSN).

RFC 8930 On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network

Authors: T. Watteyne, Ed., P. Thubert, Ed., C. Bormann.

Date: November 2020

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8930

This document provides generic rules to enable the forwarding of anIPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network. Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC4944 and Virtual Reassembly Buffers (VRBs).

RFC 8931 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery

Authors: P. Thubert, Ed..

Date: November 2020

Formats: txt xml pdf html json

Updates: RFC 4944

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8931

This document updates RFC 4944 with a protocol that forwards individual fragments across a route-over mesh and recovers them end to end, with congestion control capabilities to protect the network.

RFC 8932 Recommendations for DNS Privacy Service Operators

Authors: S. Dickinson, B. Overeinder, R. van Rijswijk-Deij, A. Mankin.

Date: October 2020

Formats: txt json html pdf xml

Also: BCP 0232

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8932

This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, as well as understanding how those decisions and the alternatives impact the privacy of users.
This document also presents a non-normative framework to assist writers of a Recursive operator Privacy Statement, analogous to DNSSecurity Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC 6841.

RFC 8933 Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection

Authors: R. Housley.

Date: October 2020

Formats: txt json pdf xml html

Updates: RFC 5652

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8933

This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed- data and authenticated-data content types are adequately protected.

RFC 8934 PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE

Authors: H. Chen, Ed., Y. Zhuang, Ed., Q. Wu, D. Ceccarelli.

Date: October 2020

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8934

This document defines a set of extensions to the stateful PCECommunication Protocol (PCEP) to enable Label Switched Path (LSP) path computation, activation, setup, and deletion based on scheduled time intervals for the LSP and the actual network resource usage in a centralized network environment, as stated in RFC 8413.

RFC 8935 Push-Based Security Event Token (SET) Delivery Using HTTP

Authors: A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin.

Date: November 2020

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8935

This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response.

RFC 8936 Poll-Based Security Event Token (SET) Delivery Using HTTP

Authors: A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin.

Date: November 2020

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8936

This specification defines how a series of Security Event Tokens(SETs) can be delivered to an intended recipient using HTTP POST overTLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient's need for assurance.

RFC 8937 Randomness Improvements for Security Protocols

Authors: C. Cremers, L. Garratt, S. Smyshlyaev, N. Sullivan, C. Wood.

Date: October 2020

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8937

Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable"cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

RFC 8938 Deterministic Networking (DetNet) Data Plane Framework

Authors: B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant.

Date: November 2020

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8938

This document provides an overall framework for the DeterministicNetworking (DetNet) data plane. It covers concepts and considerations that are generally common to any DetNet data plane specification. It describes related Controller Plane considerations as well.

RFC 8939 Deterministic Networking (DetNet) Data Plane: IP

Authors: B. Varga, Ed., J. Farkas, L. Berger, D. Fedyk, S. Bryant.

Date: November 2020

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8939

This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938).

RFC 8940 Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP)

Authors: A. DeKok.

Date: October 2020

Formats: txt json html pdf xml

Updates: RFC 5247

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8940

RFC 5247 is updated to define and clarify EAP Session-Id derivation for multiple Extensible Authentication Protocol (EAP) methods. The derivation of Session-Id was not given for EAP Subscriber IdentityModule (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA) when using the fast reconnect exchange instead of full authentication. The derivation of Session-Id for full authentication is clarified for both EAP-SIM and EAP-AKA. The derivation ofSession-Id for Protected EAP (PEAP) is also given. The definition for PEAP follows the definition for other TLS-based EAP methods.

RFC 8941 Structured Field Values for HTTP

Authors: M. Nottingham, P-H. Kamp.

Date: February 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8941

This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handleHTTP header and trailer fields, known as "Structured Fields","Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.

RFC 8942 HTTP Client Hints

Authors: I. Grigorik, Y. Weiss.

Date: February 2021

Formats: txt xml html pdf json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8942

HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers. In practice, user agents are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy.
This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints."

RFC 8943 Concise Binary Object Representation (CBOR) Tags for Date

Authors: M. Jones, A. Nadalin, J. Richter.

Date: November 2020

Formats: txt xml html pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8943

The Concise Binary Object Representation (CBOR), as specified in RFC7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
In CBOR, one point of extensibility is the definition of CBOR tags.RFC 7049 defines two tags for time: CBOR tag 0 (date/time string as per RFC 3339) and tag 1 (POSIX "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for a date text string (as per RFC 3339) for applications needing a textual date representation within theGregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time.This specification is the reference document for IANA registration of the CBOR tags defined.

RFC 8944 A YANG Data Model for Layer 2 Network Topologies

Authors: J. Dong, X. Wei, Q. Wu, M. Boucadair, A. Liu.

Date: November 2020

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8944

This document defines a YANG data model for Layer 2 network topologies. In particular, this data model augments the generic network and network topology data models with topology attributes that are specific to Layer 2.

RFC 8945 Secret Key Transaction Authentication for DNS (TSIG)

Authors: F. Dupont, S. Morris, P. Vixie, D. Eastlake 3rd, O. Gudmundsson, B. Wellington.

Date: November 2020

Formats: txt json xml pdf html

Obsoletes: RFC 2845, RFC 4635

Also: STD 0093

Status: INTERNET STANDARD

DOI: 10.17487/RFC 8945

This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server.
No recommendation is 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.
This document obsoletes RFCs 2845 and 4635.

RFC 8946 Personal Assertion Token (PASSporT) Extension for Diverted Calls

Authors: J. Peterson.

Date: February 2021

Formats: txt html pdf xml json

Updates: RFC 8224

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8946

The Personal Assertion Token (PASSporT) is specified in RFC 8225 to convey cryptographically signed information about the people involved in personal communications. This document extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios.Also specified here is an encapsulation mechanism for nesting aPASSporT within another PASSporT that assists relying parties in some diversion scenarios.
This document updates RFC 8224.

RFC 8947 Link-Layer Address Assignment Mechanism for DHCPv6

Authors: B. Volz, T. Mrugalski, C. Bernardos.

Date: December 2020

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8947

In certain environments, e.g., large-scale virtualization deployments, new devices are created in an automated manner. Such devices may have their link-layer addresses assigned in an automated fashion. With sufficient scale, the likelihood of a collision using random assignment without duplication detection is not acceptable.Therefore, an allocation mechanism is required. This document proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or are unnecessary.

RFC 8948 Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6

Authors: CJ. Bernardos, A. Mourad.

Date: December 2020

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8948

The IEEE originally structured the 48-bit Media Access Control (MAC) address space in such a way that half of it was reserved for local use. In 2017, the IEEE published a new standard (IEEE Std 802c) with a new optional Structured Local Address Plan (SLAP). It specifies different assignment approaches in four specified regions of the local MAC address space.
The IEEE is developing protocols to assign addresses (IEEE P802.1CQ).There is also work in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments.
This document proposes extensions to DHCPv6 protocols to enable aDHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that the server may allocate MAC addresses in the quadrant requested by the relay or client. A new DHCPv6 option(QUAD) is defined for this purpose.

RFC 8949 Concise Binary Object Representation (CBOR)

Authors: C. Bormann, P. Hoffman.

Date: December 2020

Formats: txt json pdf xml html

Obsoletes: RFC 7049

Also: STD 0094

Status: INTERNET STANDARD

DOI: 10.17487/RFC 8949

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.
This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.

RFC 8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop

Authors: S. Litkowski, S. Agrawal, K. Ananthamurthy, K. Patel.

Date: November 2020

Formats: txt json xml html pdf

Obsoletes: RFC 5549

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8950

Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a next-hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) orVPN-IPv4 NLRI.
This document specifies the extensions necessary to allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop forIPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the next hop to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI andVPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC5549.

RFC 8951 Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1

Authors: M. Richardson, T. Werner, W. Pan.

Date: November 2020

Formats: txt json xml html pdf

Updates: RFC 7030

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8951

This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended.
This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present.

RFC 8952 Captive Portal Architecture

Authors: K. Larose, D. Dolson, H. Liu.

Date: November 2020

Formats: txt pdf xml html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8952

This document describes a captive portal architecture. Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution.

RFC 8953 Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report

Authors: K. Moriarty.

Date: December 2020

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8953

The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop, sponsored by the Internet Society, took place on 28February and 1 March 2019 in Cambridge, Massachusetts, USA.Participants spanned regional, national, international, and enterprise Computer Security Incident Response Teams (CSIRTs), operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and participants from standards communities. This workshop continued the work started at the first CARIS workshop, with a focus on scaling incident prevention and detection as the Internet industry moves to a stronger and a more ubiquitous deployment of session encryption.

RFC 8954 Online Certificate Status Protocol (OCSP) Nonce Extension

Authors: M. Sahni, Ed..

Date: November 2020

Formats: txt pdf json xml html

Updates: RFC 6960

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8954

This document specifies the updated format of the Nonce extension in the Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate, and theNonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updatesRFC 6960.

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 8956 Dissemination of Flow Specification Rules for IPv6

Authors: C. Loibl, Ed., R. Raszuk, Ed., S. Hares, Ed..

Date: December 2020

Formats: txt html json xml pdf

Updates: RFC 8955

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8956

"Dissemination of Flow Specification Rules" (RFC 8955) provides aBorder Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets.
This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry.

RFC 8957 Synonymous Flow Label Framework

Authors: S. Bryant, M. Chen, G. Swallow, S. Sivabalan, G. Mirsky.

Date: January 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8957

RFC 8372 ("MPLS Flow Identification Considerations") describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of accomplishing this by using a technique called "Synonymous Flow Labels" in which labels that mimic the behavior of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router.

RFC 8958 Updated Registration Rules for URI.ARPA

Authors: T. Hardie.

Date: December 2020

Formats: txt json html xml pdf

Updates: RFC 3405

Also: BCP 0065

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8958

This document updates RFC 3405 by removing references to the IETF tree from the procedures for requesting that a URI scheme be inserted into the URI.ARPA zone.

RFC 8959 The "secret-token" URI Scheme

Authors: M. Nottingham.

Date: January 2021

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8959

This document registers the "secret-token" URI scheme to aid in the identification of authentication tokens.

RFC 8960 A YANG Data Model for MPLS Base

Authors: T. Saad, K. Raza, R. Gandhi, X. Liu, V. Beeram.

Date: December 2020

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8960

This document contains a specification of the MPLS base YANG data model. The MPLS base YANG data model serves as a base framework for configuring and managing an MPLS switching subsystem on an MPLS- enabled router. It is expected that other MPLS YANG data models(e.g., MPLS Label Switched Path (LSP) static, LDP, or RSVP-TE YANG data models) will augment the MPLS base YANG data model.

RFC 8961 Requirements for Time-Based Loss Detection

Authors: M. Allman.

Date: November 2020

Formats: txt json pdf xml html

Also: BCP 0233

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8961

Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, ultimately, protocols can only count on the passage of time without delivery confirmation to declare a packet"lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness; therefore, no implementation suits all situations. This document provides high- level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation.

RFC 8962 Establishing the Protocol Police

Authors: G. Grover, N. ten Oever, C. Cath, S. Sahib.

Date: 1 April 2021

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8962

One mantra of the IETF is, "We are not the Protocol Police."However, to ensure that protocols are implemented and deployed in full compliance with the IETF's standards, it is important to set up a body that is responsible for assessing and enforcing correct protocol behavior.
This document formally establishes the Protocol Police. It defines the body and sets out what aspects of IETF protocols they will police. This document acts as a point of reference for networking engineers, law enforcement officials, government representatives, and others. It also provides advice on how to report issues to theProtocol Police.

RFC 8963 Evaluation of a Sample of RFCs Produced in 2018

Authors: C. Huitema.

Date: January 2021

Formats: txt html json xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8963

This document presents the author's effort to understand the delays involved in publishing an idea in the IETF or through the IndependentStream, from the first individual draft to the publication of theRFC. We analyze a set of randomly chosen RFCs approved in 2018, looking for history and delays. We also use two randomly chosen sets of RFCs published in 2008 and 1998 for comparing delays seen in 2018 to those observed 10 or 20 years ago. The average RFC in the 2018 sample was produced in 3 years and 4 months, of which 2 years and 10 months were spent in the working group, 3 to 4 months for IETF consensus and IESG review, and 3 to 4 months in RFC production. The main variation in RFC production delays comes from the AUTH48 phase.
We also measure the number of citations of the chosen RFC usingSemantic Scholar, and compare citation counts with what we know about deployment. We show that citation counts indicate academic interest, but correlate only loosely with deployment or usage of the specifications. Counting web references could complement that.

RFC 8964 Deterministic Networking (DetNet) Data Plane: MPLS

Authors: B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant, J. Korhonen.

Date: January 2021

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8964

This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS TrafficEngineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework.

RFC 8965 Applicability of the Babel Routing Protocol

Authors: J. Chroboczek.

Date: January 2021

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8965

Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols.

RFC 8966 The Babel Routing Protocol

Authors: J. Chroboczek, D. Schinazi.

Date: January 2021

Formats: txt html pdf xml json

Obsoletes: RFC 6126, RFC 7557

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8966

Babel is a loop-avoiding, distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol and obsoletes RFC 6126 and RFC 7557.

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 8968 Babel Routing Protocol over Datagram Transport Layer Security

Authors: A. Décimo, D. Schinazi, J. Chroboczek.

Date: January 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8968

The Babel Routing Protocol does not contain any means to authenticate neighbours or provide integrity or confidentiality for messages sent between them. This document specifies a mechanism to ensure these properties using Datagram Transport Layer Security (DTLS).

RFC 8969 A Framework for Automating Service and Network Management with YANG

Authors: Q. Wu, Ed., M. Boucadair, Ed., D. Lopez, C. Xie, L. Geng.

Date: January 2021

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8969

Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.
This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF.

RFC 8970 IMAP4 Extension: Message Preview Generation

Authors: M. Slusarz.

Date: December 2020

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8970

This document specifies an Internet Message Access Protocol (IMAP) protocol extension that allows a client to request a server-generated abbreviated text representation of message data that is useful as a contextual preview of the entire message.

RFC 8971 Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN)

Authors: S. Pallagatti, Ed., G. Mirsky, Ed., S. Paragiri, V. Govindan, M. Mudigonda.

Date: December 2020

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8971

This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol in point-to-point Virtual eXtensible LocalArea Network (VXLAN) tunnels used to form an overlay network.

RFC 8972 Simple Two-Way Active Measurement Protocol Optional Extensions

Authors: G. Mirsky, X. Min, H. Nydell, R. Foote, A. Masputra, E. Ruffini.

Date: January 2021

Formats: txt html json pdf xml

Updates: RFC 8762

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8972

This document describes optional extensions to Simple Two-way ActiveMeasurement Protocol (STAMP) that enable measurement of performance metrics. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762.

RFC 8973 DDoS Open Threat Signaling (DOTS) Agent Discovery

Authors: M. Boucadair, T. Reddy.K.

Date: January 2021

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8973

This document specifies mechanisms to configure DDoS Open ThreatSignaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS signal channel Call Home. It can be useful to know the appropriate DOTS server for a given location in order to engage mitigation actions. This is true even in cases where the DOTS client cannot localize the attack: cases where it only knows that some resources are under attack and that help is needed.

RFC 8974 Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)

Authors: K. Hartke, M. Richardson.

Date: January 2021

Formats: txt json pdf xml html

Updates: RFC 7252, RFC 8323

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8974

This document provides considerations for alleviating ConstrainedApplication Protocol (CoAP) clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths.
This document updates RFCs 7252 and 8323 with an extended definition of the "TKL" field in the CoAP message header.

RFC 8975 Network Coding for Satellite Systems

Authors: N. Kuhn, Ed., E. Lochin, Ed..

Date: January 2021

Formats: txt json html pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8975

This document is a product of the Coding for Efficient NetworkCommunications Research Group (NWCRG). It conforms to the directions found in the NWCRG taxonomy (RFC 8406).
The objective is to contribute to a larger deployment of NetworkCoding techniques in and above the network layer in satellite communication systems. This document also identifies open research issues related to the deployment of Network Coding in satellite communication systems.

RFC 8976 Message Digest for DNS Zones

Authors: D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. Hardaker.

Date: February 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8976

This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest.The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes.
ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets(DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications.
As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation.However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones.

RFC 8977 Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging

Authors: M. Loffredo, M. Martinelli, S. Hollenbeck.

Date: January 2021

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8977

The Registration Data Access Protocol (RDAP) does not include core functionality for clients to provide sorting and paging parameters for control of large result sets. This omission can lead to unpredictable server processing of queries and client processing of responses. This unpredictability can be greatly reduced if clients can provide servers with their preferences for managing large responses. This document describes RDAP query extensions that allow clients to specify their preferences for sorting and paging result sets.

RFC 8978 Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events

Authors: F. Gont, J. Žorž, R. Patterson.

Date: March 2021

Formats: txt xml json pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8978

In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit and reliable signaling of that condition (such as when a Customer Edge router crashes and reboots without knowledge of the previously employed prefixes), hosts on the local network may continue using stale prefixes for an unacceptably long time (on the order of several days), thus resulting in connectivity problems. This document describes this issue and discusses operational workarounds that may help to improve network robustness. Additionally, it highlights areas where further work may be needed.

RFC 8979 Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH)

Authors: B. Sarikaya, D. von Hugo, M. Boucadair.

Date: February 2021

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8979

This document defines the Subscriber and Performance PolicyIdentifier Context Headers. These Variable-Length Context Headers can be carried in the Network Service Header (NSH) and are used to inform Service Functions (SFs) of subscriber- and performance-related information for the sake of policy enforcement and appropriateService Function Chaining (SFC) operations. The structure of eachContext Header and their use and processing by NSH-aware nodes are described.

RFC 8980 Report from the IAB Workshop on Design Expectations vs

Authors: Deployment Reality in Protocol Development. J. Arkko, T. Hardie.

Date: February 2021

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 8980

The Design Expectations vs. Deployment Reality in ProtocolDevelopment Workshop was convened by the Internet Architecture Board(IAB) in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6

Authors: F. Gont, S. Krishnan, T. Narten, R. Draves.

Date: February 2021

Formats: txt json xml pdf html

Obsoletes: RFC 4941

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8981

This document describes an extension to IPv6 Stateless AddressAutoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.

RFC 8982 Registration Data Access Protocol (RDAP) Partial Response

Authors: M. Loffredo, M. Martinelli.

Date: February 2021

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8982

The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses. Servers will only return full responses that include all of the information that a client is authorized to receive. A partial response capability that limits the amount of information returned, especially in the case of search queries, could bring benefits to both clients and servers. This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response.

RFC 8983 Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence

Authors: M. Boucadair.

Date: February 2021

Formats: txt html pdf xml json

Updates: RFC 7296

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8983

This document specifies new Internet Key Exchange Protocol Version 2(IKEv2) notification status types to better manage IPv4 and IPv6 coexistence by allowing the responder to signal to the initiator which address families are allowed.
This document updates RFC 7296.

RFC 8984 JSCalendar: A JSON Representation of Calendar Data

Authors: N. Jenkins, R. Stepanek.

Date: July 2021

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8984

This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based onJSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate.

RFC 8985 The RACK-TLP Loss Detection Algorithm for TCP

Authors: Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha.

Date: February 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8985

This document presents the RACK-TLP loss detection algorithm for TCP.RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has two parts. Recent Acknowledgment(RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DupAck threshold approach.

RFC 8986 Segment Routing over IPv6 (SRv6) Network Programming

Authors: C. Filsfils, Ed., P. Camarillo, Ed., J. Leddy, D. Voyer, S. Matsushima, Z. Li.

Date: February 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8986

The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.
Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.
This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.

RFC 8987 DHCPv6 Prefix Delegating Relay Requirements

Authors: I. Farrer, N. Kottapalli, M. Hunek, R. Patterson.

Date: February 2021

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8987

This document describes operational problems that are known to occur when using DHCPv6 relays with prefix delegation. These problems can prevent successful delegation and result in routing failures. To address these problems, this document provides necessary functional requirements for operating DHCPv6 relays with prefix delegation.
It is recommended that any network operator using DHCPv6 prefix delegation with relays ensure that these requirements are followed on their networks.

RFC 8989 Additional Criteria for Nominating Committee Eligibility

Authors: B. Carpenter, S. Farrell.

Date: February 2021

Formats: txt json xml pdf html

Obsoleted by: RFC 9389

Status: EXPERIMENTAL

DOI: 10.17487/RFC 8989

This document defines a process experiment under RFC 3933 that temporarily updates the criteria for qualifying volunteers to participate in the IETF Nominating Committee. It therefore also updates the criteria for qualifying signatories to a community recall petition. The purpose is to make the criteria more flexible in view of increasing remote participation in the IETF and a reduction in face-to-face meetings. The experiment is of fixed duration and will apply to one, or at most two, consecutive Nominating Committee cycles, starting in 2021. This document temporarily varies the rules in RFC 8713.

RFC 8990 GeneRic Autonomic Signaling Protocol (GRASP)

Authors: C. Bormann, B. Carpenter, Ed., B. Liu, Ed..

Date: May 2021

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8990

This document specifies the GeneRic Autonomic Signaling Protocol(GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features.

RFC 8991 GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API)

Authors: B. Carpenter, B. Liu, Ed., W. Wang, X. Gong.

Date: May 2021

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 8991

This document is a conceptual outline of an Application ProgrammingInterface (API) for the GeneRic Autonomic Signaling Protocol (GRASP).Such an API is needed for Autonomic Service Agents (ASAs) calling theGRASP protocol module to exchange Autonomic Network messages with other ASAs. Since GRASP is designed to support asynchronous operations, the API will need to be adapted according to the support for asynchronicity in various programming languages and operating systems.

RFC 8992 Autonomic IPv6 Edge Prefix Management in Large-Scale Networks

Authors: S. Jiang, Ed., Z. Du, B. Carpenter, Q. Sun.

Date: May 2021

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8992

This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of this document is to use it for validation of the design of various components of the Autonomic Networking Infrastructure.

RFC 8993 A Reference Model for Autonomic Networking

Authors: M. Behringer, Ed., B. Carpenter, T. Eckert, L. Ciavaglia, J. Nobre.

Date: May 2021

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 8993

This document describes a reference model for Autonomic Networking for managed networks. It defines the behavior of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.

RFC 8994 An Autonomic Control Plane (ACP)

Authors: T. Eckert, Ed., M. Behringer, Ed., S. Bjarnason.

Date: May 2021

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8994

Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the"Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured.

RFC 8995 Bootstrapping Remote Secure Key Infrastructure (BRSKI)

Authors: M. Pritikin, M. Richardson, T. Eckert, M. Behringer, K. Watsen.

Date: May 2021

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8995

This document specifies automated bootstrapping of an AutonomicControl Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process theBootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.

RFC 8996 Deprecating TLS 1.0 and TLS 1.1

Authors: K. Moriarty, S. Farrell.

Date: March 2021

Formats: txt html json pdf xml

Obsoletes: RFC 5469, RFC 7507

Updates: RFC 3261, RFC 3329, RFC 3436, RFC 3470, RFC 3501, RFC 3552, RFC 3568, RFC 3656, RFC 3749, RFC 3767, RFC 3856, RFC 3871, RFC 3887, RFC 3903, RFC 3943, RFC 3983, RFC 4097, RFC 4111, RFC 4162, RFC 4168, RFC 4217, RFC 4235, RFC 4261, RFC 4279, RFC 4497, RFC 4513, RFC 4531, RFC 4540, RFC 4582, RFC 4616, RFC 4642, RFC 4680, RFC 4681, RFC 4712, RFC 4732, RFC 4743, RFC 4744, RFC 4785, RFC 4791, RFC 4823, RFC 4851, RFC 4964, RFC 4975, RFC 4976, RFC 4992, RFC 5018, RFC 5019, RFC 5023, RFC 5024, RFC 5049, RFC 5054, RFC 5091, RFC 5158, RFC 5216, RFC 5238, RFC 5263, RFC 5281, RFC 5364, RFC 5415, RFC 5422, RFC 5456, RFC 5734, RFC 5878, RFC 5953, RFC 6012, RFC 6042, RFC 6083, RFC 6084, RFC 6176, RFC 6347, RFC 6353, RFC 6367, RFC 6460, RFC 6614, RFC 6739, RFC 6749, RFC 6750, RFC 7030, RFC 7465, RFC 7525, RFC 7562, RFC 7568, RFC 8261, RFC 8422

Also: BCP 0195

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 8996

This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions.TLS version 1.2 became the recommended version for IETF protocols in2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions.Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.
This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC4347) but not DTLS version 1.2, and there is no DTLS version 1.1.
This document updates many RFCs that normatively refer to TLS version1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.

RFC 8997 Deprecation of TLS 1.1 for Email Submission and Access

Authors: L. Velvindron, S. Farrell.

Date: March 2021

Formats: txt html pdf xml json

Updates: RFC 8314

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 8997

This specification updates the current recommendation for the use of the Transport Layer Security (TLS) protocol to provide confidentiality of email between a Mail User Agent (MUA) and a MailSubmission Server or Mail Access Server. This document updates RFC8314.

RFC 8998 ShangMi (SM) Cipher Suites for TLS 1.3

Authors: P. Yang.

Date: March 2021

Formats: txt json html pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 8998

This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3.
The use of these algorithms with TLS 1.3 is not endorsed by the IETF.The SM algorithms are becoming mandatory in China, so this document provides a description of how to use the SM algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations.

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 9000 QUIC: A UDP-Based Multiplexed and Secure Transport

Authors: J. Iyengar, Ed., M. Thomson, Ed..

Date: May 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9000

This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration ofTLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

RFC 9001 Using TLS to Secure QUIC

Authors: M. Thomson, Ed., S. Turner, Ed..

Date: May 2021

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9001

This document describes how Transport Layer Security (TLS) is used to secure QUIC.

RFC 9002 QUIC Loss Detection and Congestion Control

Authors: J. Iyengar, Ed., I. Swett, Ed..

Date: May 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9002

This document describes loss detection and congestion control mechanisms for QUIC.

RFC 9003 Extended BGP Administrative Shutdown Communication

Authors: J. Snijders, J. Heitz, J. Scudder, A. Azimov.

Date: January 2021

Formats: txt pdf xml json html

Obsoletes: RFC 8203

Updates: RFC 4486

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9003

This document enhances the BGP Cease NOTIFICATION message"Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short free-form message to describe why a BGP session was shut down or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP AdministrativeShutdown Communication of up to 255 octets to improve communication using multibyte character sets.

RFC 9004 Updates for the Back-to-Back Frame Benchmark in RFC 2544

Authors: A. Morton.

Date: May 2021

Formats: txt html pdf xml json

Updates: RFC 2544

Status: INFORMATIONAL

DOI: 10.17487/RFC 9004

Fundamental benchmarking methodologies for network interconnect devices of interest to the IETF are defined in RFC 2544. This memo updates the procedures of the test to measure the Back-to-Back Frames benchmark of RFC 2544, based on further experience.
This memo updates Section 26.4 of RFC 2544.

RFC 9005 Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs)

Authors: S. Litkowski, S. Sivabalan, J. Tantsura, J. Hardwick, C. Li.

Date: March 2021

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9005

This document introduces a simple mechanism to associate policies with a group of Label Switched Paths (LSPs) via an extension to thePath Computation Element Communication Protocol (PCEP). The extension allows a PCEP speaker to advertise to a PCEP peer that a particular LSP belongs to a particular Policy Association Group(PAG).

RFC 9006 TCP Usage Guidance in the Internet of Things (IoT)

Authors: C. Gomez, J. Crowcroft, M. Scharf.

Date: March 2021

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9006

This document provides guidance on how to implement and use theTransmission Control Protocol (TCP) in Constrained-Node Networks(CNNs), which are a characteristic of the Internet of Things (IoT).Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding trade-offs. The objective is to help embedded developers with decisions on which TCP features to use.

RFC 9007 Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP)

Authors: R. Ouazana, Ed..

Date: March 2021

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9007

This document specifies a data model for handling Message DispositionNotifications (MDNs) (see RFC 8098) in the JSON Meta ApplicationProtocol (JMAP) (see RFCs 8620 and 8621).

RFC 9008 Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane

Authors: M.I. Robles, M. Richardson, P. Thubert.

Date: April 2021

Formats: txt html xml json pdf

Updates: RFC 6553, RFC 6550, RFC 8138

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9008

This document looks at different data flows through Low-Power andLossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RPL Packet Information (RPI) Option Type(RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data plane. This analysis provides the basis upon which to design efficient compression of these headers. This document updates RFC 6553 by adding a change to theRPI Option Type. Additionally, this document updates RFC 6550 by defining a flag in the DODAG Information Object (DIO) Configuration option to indicate this change and updates RFC 8138 as well to consider the new Option Type when the RPL Option is decompressed.

RFC 9009 Efficient Route Invalidation

Authors: R.A. Jadhav, Ed., P. Thubert, R.N. Sahoo, Z. Cao.

Date: April 2021

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9009

This document explains the problems associated with the use of No-Path Destination Advertisement Object (NPDAO) messaging in RFC 6550 and also discusses the requirements for an optimized route invalidation messaging scheme. Further, this document specifies a new proactive route invalidation message called the "DestinationCleanup Object" (DCO), which fulfills requirements for optimized route invalidation messaging.

RFC 9010 Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves

Authors: P. Thubert, Ed., M. Richardson.

Date: April 2021

Formats: txt html pdf xml json

Updates: RFC 6550, RFC 6775, RFC 8505

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9010

This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 6775, and 8505.

RFC 9011 Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN

Authors: O. Gimenez, Ed., I. Petrov, Ed..

Date: April 2021

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9011

The Static Context Header Compression and fragmentation (SCHC) specification (RFC 8724) describes generic header compression and fragmentation techniques for Low-Power Wide Area Network (LPWAN) technologies. SCHC is a generic mechanism designed for great flexibility so that it can be adapted for any of the LPWAN technologies.
This document defines a profile of SCHC (RFC 8724) for use in LoRaWAN networks and provides elements such as efficient parameterization and modes of operation.

RFC 9012 The BGP Tunnel Encapsulation Attribute

Authors: K. Patel, G. Van de Velde, S. Sangli, J. Scudder.

Date: April 2021

Formats: txt json xml pdf html

Obsoletes: RFC 5512, RFC 5566

Updates: RFC 5640

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9012

This document defines a BGP path attribute known as the "TunnelEncapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.
This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any TunnelEncapsulation attribute where load balancing is desired.

RFC 9013 OSPF Advertisement of Tunnel Encapsulations

Authors: X. Xu, Ed., B. Decraene, Ed., R. Raszuk, L. Contreras, L. Jalil.

Date: April 2021

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9013

Networks use tunnels for a variety of reasons. A large variety of tunnel types are defined, and the tunnel encapsulator router needs to select a type of tunnel that is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF RouterInformation Link State Advertisements (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator.

RFC 9014 Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks

Authors: J. Rabadan, Ed., S. Sathappan, W. Henderickx, A. Sajassi, J. Drake.

Date: May 2021

Formats: txt xml html pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9014

This document describes how Network Virtualization Overlays (NVOs) can be connected to a Wide Area Network (WAN) in order to extend theLayer 2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running EthernetVirtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN) technologies used in the WAN, such as Virtual Private LAN Services(VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS),EVPN, or PBB-EVPN. It also describes how the existing technical specifications apply to the interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as theInterconnect Ethernet Segment (I-ES), to provide multihoming. This document also describes the use of the Unknown MAC Route (UMR) to avoid issues of a Media Access Control (MAC) scale on Data CenterNetwork Virtualization Edge (NVE) devices.

RFC 9015 BGP Control Plane for the Network Service Header in Service Function Chaining

Authors: A. Farrel, J. Drake, E. Rosen, J. Uttaro, L. Jalil.

Date: June 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9015

This document describes the use of BGP as a control plane for networks that support service function chaining. The document introduces a new BGP address family called the "Service FunctionChain (SFC) Address Family Identifier / Subsequent Address FamilyIdentifier" (SFC AFI/SAFI) with two Route Types. One Route Type is originated by a node to advertise that it hosts a particular instance of a specified service function. This Route Type also provides"instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other Route Type is used by a controller to advertise the paths of "chains" of service functions and give a unique designator to each such path so that they can be used in conjunction with the Network Service Header (NSH) defined in RFC 8300.
This document adopts the service function chaining architecture described in RFC 7665.

RFC 9016 Flow and Service Information Model for Deterministic Networking (DetNet)

Authors: B. Varga, J. Farkas, R. Cummings, Y. Jiang, D. Fedyk.

Date: March 2021

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9016

This document describes the flow and service information model forDeterministic Networking (DetNet). These models are defined for IP and MPLS DetNet data planes.

RFC 9017 Special-Purpose Label Terminology

Authors: L. Andersson, K. Kompella, A. Farrel.

Date: April 2021

Formats: txt json html pdf xml

Updates: RFC 3032, RFC 7274

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9017

This document discusses and recommends terminology that may be used when MPLS Special-Purpose Labels (SPLs) are specified and documented.
This document applies that terminology change to the relevant IANA registry and also clarifies the use of the Entropy Label Indicator(7) when immediately preceded by the Extension Label (15).
This document updates RFCs 3032 and 7274.

RFC 9018 Interoperable Domain Name System (DNS) Server Cookies

Authors: O. Sury, W. Toorop, D. Eastlake 3rd, M. Andrews.

Date: April 2021

Formats: txt html pdf xml json

Updates: RFC 7873

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9018

DNS Cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism that provide limited protection to DNS servers and clients against a variety of denial-of-service amplification, forgery, or cache-poisoning attacks by off-path attackers.
This document updates RFC 7873 with precise directions for creatingServer Cookies so that an anycast server set including diverse implementations will interoperate with standard clients, with suggestions for constructing Client Cookies in a privacy-preserving fashion, and with suggestions on how to update a Server Secret. AnIANA registry listing the methods and associated pseudorandom function suitable for creating DNS Server Cookies has been created with the method described in this document as the first and, as of the time of publication, only entry.

RFC 9019 A Firmware Update Architecture for Internet of Things

Authors: B. Moran, H. Tschofenig, D. Brown, M. Meriac.

Date: April 2021

Formats: txt html json pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9019

Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.
In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.

RFC 9020 YANG Data Model for Segment Routing

Authors: S. Litkowski, Y. Qu, A. Lindem, P. Sarkar, J. Tantsura.

Date: May 2021

Formats: txt xml html pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9020

This document defines three YANG data models. The first is forSegment Routing (SR) configuration and operation, which is to be augmented by different Segment Routing data planes. The next is aYANG data model that defines a collection of generic types and groupings for SR. The third module defines the configuration and operational states for the Segment Routing MPLS data plane.

RFC 9021 Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE)

Authors: D. Atkins.

Date: May 2021

Formats: txt xml html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9021

This document specifies the conventions for using the Walnut DigitalSignature Algorithm (WalnutDSA) for digital signatures with the CBORObject Signing and Encryption (COSE) syntax. WalnutDSA is a lightweight, quantum-resistant signature scheme based on GroupTheoretic Cryptography with implementation and computational efficiency of signature verification in constrained environments, even on 8- and 16-bit platforms.
The goal of this publication is to document a way to use the lightweight, quantum-resistant WalnutDSA signature algorithm in COSE in a way that would allow multiple developers to build compatible implementations. As of this publication, the security properties ofWalnutDSA have not been evaluated by the IETF and its use has not been endorsed by the IETF.
WalnutDSA and the Walnut Digital Signature Algorithm are trademarks of Veridify Security Inc.

RFC 9022 Domain Name Registration Data (DNRD) Objects Mapping

Authors: G. Lozano, J. Gould, C. Thippeswamy.

Date: May 2021

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9022

This document specifies the format, contents, and semantics of DomainName Registration Data (DNRD) escrow deposits for a domain name registry.

RFC 9023 Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)

Authors: B. Varga, Ed., J. Farkas, A. Malis, S. Bryant.

Date: June 2021

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9023

This document specifies the Deterministic Networking IP data plane when operating over a Time-Sensitive Networking (TSN) sub-network.This document does not define new procedures or processes. Whenever this document makes statements or recommendations, these are taken from normative text in the referenced RFCs.

RFC 9024 Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS

Authors: B. Varga, Ed., J. Farkas, A. Malis, S. Bryant, D. Fedyk.

Date: June 2021

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9024

This document specifies the Deterministic Networking data plane whenTime-Sensitive Networking (TSN) networks are interconnected over aDetNet MPLS network.

RFC 9025 Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP

Authors: B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant.

Date: April 2021

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9025

This document specifies the MPLS Deterministic Networking (DetNet) data plane operation and encapsulation over an IP network. The approach is based on the operation of MPLS-over-UDP technology.

RFC 9026 Multicast VPN Fast Upstream Failover

Authors: T. Morin, Ed., R. Kebler, Ed., G. Mirsky, Ed..

Date: April 2021

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9026

This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using"Bidirectional Forwarding Detection (BFD) for Multipoint Networks"(RFC 8562) and the new BGP Attribute, BFD Discriminator. Also, this document introduces a new BGP Community, Standby PE, extending BGPMulticast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE.

RFC 9027 Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks

Authors: M. Dolly, C. Wendt.

Date: June 2021

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9027

This document adds new assertion values for a Resource PriorityHeader ("rph") claim and a new SIP Priority Header ("sph") claim for protection of the "psap-callback" value as part of the "rph" PersonalAssertion Token (PASSporT) extension in support of the security of emergency services networks for emergency call origination and callback.

RFC 9028 Native NAT Traversal Mode for the Host Identity Protocol

Authors: A. Keränen, J. Melén, M. Komu, Ed..

Date: July 2021

Formats: txt xml pdf html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9028

This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to the kernel-space dependencies of HIP.

RFC 9029 Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries

Authors: A. Farrel.

Date: June 2021

Formats: txt html xml pdf json

Obsoleted by: RFC 9552

Updates: RFC 7752

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9029

RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS).IANA created a registry consistent with that document called "BorderGateway Protocol - Link State (BGP-LS) Parameters" with a number of subregistries. The allocation policy applied by IANA for those registries is "Specification Required", as defined in RFC 8126.
This document updates RFC 7752 by changing the allocation policy for all of the registries to "Expert Review" and by updating the guidance to the designated experts.

RFC 9030 An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)

Authors: P. Thubert, Ed..

Date: May 2021

Formats: txt pdf xml html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9030

This document describes a network architecture that provides low- latency, low-jitter, and high-reliability packet delivery. It combines a high-speed powered backbone and subnetworks using IEEE802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of low-power wireless deterministic applications.

RFC 9031 Constrained Join Protocol (CoJP) for 6TiSCH

Authors: M. Vučinić, Ed., J. Simon, K. Pister, M. Richardson.

Date: May 2021

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9031

This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over theTime-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a singleCoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTfulEnvironments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR(Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework.

RFC 9032 Encapsulation of 6TiSCH Join and Enrollment Information Elements

Authors: D. Dujovne, Ed., M. Richardson.

Date: May 2021

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9032

In the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a TSCH network transmit EnhancedBeacon (EB) frames to announce the presence of the network. This document provides a mechanism by which additional information critical for new nodes (pledges) and long-sleeping nodes may be carried within the EB in order to conserve use of broadcast opportunities.

RFC 9033 6TiSCH Minimal Scheduling Function (MSF)

Authors: T. Chang, Ed., M. Vučinić, X. Vilajosana, S. Duquennoy, D. Dujovne.

Date: May 2021

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9033

This specification defines the "IPv6 over the TSCH mode of IEEE802.15.4" (6TiSCH) Minimal Scheduling Function (MSF). ThisScheduling Function describes both the behavior of a node when joining the network and how the communication schedule is managed in a distributed fashion. MSF is built upon the 6TiSCH OperationSublayer Protocol (6P) and the minimal security framework for 6TiSCH.

RFC 9034 Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

Authors: L. Thomas, S. Anamalamudi, S.V.R. Anand, M. Hegde, C. Perkins.

Date: June 2021

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9034

This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time-critical machine-to-machine (M2M) applications running on Internet-enabled devices that operate within time-synchronized networks. This document also specifies a representation for the deadline time values in such networks.

RFC 9035 A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header

Authors: P. Thubert, Ed., L. Zhao.

Date: April 2021

Formats: txt html xml pdf json

Updates: RFC 8138

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9035

This document updates RFC 8138 by defining a bit in the RoutingProtocol for Low-Power and Lossy Networks (RPL) Destination-OrientedDirected Acyclic Graph (DODAG) Configuration option to indicate whether compression is used within the RPL Instance and to specify the behavior of nodes compliant with RFC 8138 when the bit is set and unset.

RFC 9036 Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy

Authors: R. Gellens.

Date: June 2021

Formats: txt pdf json xml html

Updates: RFC 5222

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9036

This document changes the policy of the "Location-to-ServiceTranslation (LoST) Location Profiles" IANA registry established byRFC 5222 from Standards Action to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values.

RFC 9037 Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN)

Authors: B. Varga, Ed., J. Farkas, A. Malis, S. Bryant.

Date: June 2021

Formats: txt pdf json xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9037

This document specifies the Deterministic Networking (DetNet) MPLS data plane when operating over an IEEE 802.1 Time-SensitiveNetworking (TSN) sub-network. This document does not define new procedures or processes. Whenever this document makes statements or recommendations, they are taken from normative text in the referencedRFCs.

RFC 9038 Extensible Provisioning Protocol (EPP) Unhandled Namespaces

Authors: J. Gould, M. Casanova.

Date: May 2021

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9038

The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs, and an "unhandled namespace" is one that is associated with a service not supported by the client. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs and that maintains compliance with the negotiated services defined in RFC 5730.

RFC 9039 Uniform Resource Names for Device Identifiers

Authors: J. Arkko, C. Jennings, Z. Shelby.

Date: June 2021

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9039

This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories. A URN-based representation can be passed along in applications that need the information.

RFC 9040 TCP Control Block Interdependence

Authors: J. Touch, M. Welzl, S. Islam.

Date: July 2021

Formats: txt json xml html pdf

Obsoletes: RFC 2140

Status: INFORMATIONAL

DOI: 10.17487/RFC 9040

This memo provides guidance to TCP implementers that is intended to help improve connection convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of sharing TCP state, as typically represented in TCPControl Blocks, among similar concurrent or consecutive connections.

RFC 9041 Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry

Authors: L. Andersson, M. Chen, C. Pignataro, T. Saad.

Date: July 2021

Formats: txt json xml pdf html

Updates: RFC 8029, RFC 8611

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9041

This document updates RFCs 8029 and 8611, both of which define IANA registries for MPLS Label Switched Path (LSP) Ping. In particular, the registration procedure "Private Use" (previously known as "VendorPrivate Use") has been changed to "First Come First Served" for theTLV and sub-TLV registries.
It also updates the description of the procedures for the responses sent when an unknown or erroneous code point is found. The updates are to clarify and align this namespace with recent developments, e.g., aligning terminology with RFC 8126 instead of the now obsoletedRFC 5226 (both titled "Guidelines for Writing an IANA ConsiderationsSection in RFCs").

RFC 9042 Sieve Email Filtering: Delivery by MAILBOXID

Authors: B. Gondwana, Ed..

Date: June 2021

Formats: txt pdf xml html json

Updates: RFC 5228

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9042

The OBJECTID capability of IMAP (RFC 8474) allows clients to identify mailboxes by a unique identifier that survives renaming.
This document extends the Sieve email filtering language (RFC 5228) to allow using that same unique identifier as a target for fileinto rules and for testing the existence of mailboxes.

RFC 9043 FFV1 Video Coding Format Versions 0, 1, and 3

Authors: M. Niedermayer, D. Rice, J. Martinez.

Date: August 2021

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9043

This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format.

RFC 9044 Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)

Authors: R. Housley.

Date: June 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9044

This document specifies the conventions for using the AES-GMACMessage Authentication Code algorithm with the Cryptographic MessageSyntax (CMS) as specified in RFC 5652.

RFC 9045 Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)

Authors: R. Housley.

Date: June 2021

Formats: txt pdf xml json html

Updates: RFC 4211

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9045

This document updates the cryptographic algorithm requirements for the Password-Based Message Authentication Code in the Internet X.509Public Key Infrastructure Certificate Request Message Format (CRMF) specified in RFC 4211.

RFC 9046 Babel Information Model

Authors: B. Stark, M. Jethanandani.

Date: June 2021

Formats: txt html json xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9046

The Babel information model provides structured data elements for aBabel implementation reporting its current state and may allow limited configuration of some such data elements. This information model can be used as a basis for creating data models under various data modeling regimes. This information model only includes parameters and parameter values useful for managing Babel over IPv6.

RFC 9047 Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)

Authors: J. Rabadan, Ed., S. Sathappan, K. Nagaraj, W. Lin.

Date: June 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9047

This document defines an Extended Community that is advertised along with an Ethernet Virtual Private Network (EVPN) Media Access Control(MAC) / IP Advertisement route and carries information relevant to the Address Resolution Protocol (ARP) / Neighbor Discovery (ND) resolution so that an EVPN Provider Edge (PE) implementing a proxy-ARP/ND function in broadcast domains (BDs) or an ARP/ND function onIntegrated Routing and Bridging (IRB) interfaces can reply to ARPRequests or Neighbor Solicitation (NS) messages with the correct information.

RFC 9048 Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')

Authors: J. Arkko, V. Lehtovirta, V. Torvinen, P. Eronen.

Date: October 2021

Formats: txt json html xml pdf

Updates: RFC 5448, RFC 4187

Status: INFORMATIONAL

DOI: 10.17487/RFC 9048

The 3GPP mobile network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC5448 (EAP-AKA') was an improved version of EAP-AKA.
This document is the most recent specification of EAP-AKA', including, for instance, details about and references related to operating EAP-AKA' in 5G networks.
EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-SHA-1, which is used in EAP-AKA.
This version of the EAP-AKA' specification defines the protocol behavior for both 4G and 5G deployments, whereas the previous version defined protocol behavior for 4G deployments only. While EAP-AKA' as defined in RFC 5448 is not obsolete, this document defines the most recent and fully backwards-compatible specification of EAP-AKA'.This document updates both RFCs 4187 and 5448.

RFC 9049 Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)

Authors: S. Dawkins, Ed..

Date: June 2021

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9049

This document is a product of the Path Aware Networking ResearchGroup (PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy PathAware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons forPath Aware networking researchers.
This document contains that catalog and analysis.

RFC 9050 Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs

Authors: Z. Li, S. Peng, M. Negi, Q. Zhao, C. Zhou.

Date: July 2021

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9050

The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems.
A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the LabelSwitched Path (LSP) can be calculated/set up/initiated and the label- forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible.
This document specifies the procedures and Path Computation ElementCommunication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static LSP.

RFC 9051 Internet Message Access Protocol (IMAP) - Version 4rev2

Authors: A. Melnikov, Ed., B. Leiba, Ed..

Date: August 2021

Formats: txt json pdf xml html

Obsoletes: RFC 3501

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9051

The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders.IMAP4rev2 also provides the capability for an offline client to resynchronize with the server.
IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.
IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified inRFC 6409.

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 9053 CBOR Object Signing and Encryption (COSE): Initial Algorithms

Authors: J. Schaad.

Date: August 2022

Formats: txt xml html pdf json

Obsoletes: RFC 8152

Status: INFORMATIONAL

DOI: 10.17487/RFC 9053

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 a set of algorithms that can be used with the CBORObject Signing and Encryption (COSE) protocol (RFC 9052).
This document, along with RFC 9052, obsoletes RFC 8152.

RFC 9054 CBOR Object Signing and Encryption (COSE): Hash Algorithms

Authors: J. Schaad.

Date: August 2022

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9054

The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers.

RFC 9055 Deterministic Networking (DetNet) Security Considerations

Authors: E. Grossman, Ed., T. Mizrahi, A. Hacker.

Date: June 2021

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9055

A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e.,"jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties.
This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection.
This document also addresses security considerations specific to theIP and MPLS data plane technologies, thereby complementing theSecurity Considerations sections of those documents.

RFC 9056 Deterministic Networking (DetNet) Data Plane: IP over MPLS

Authors: B. Varga, Ed., L. Berger, D. Fedyk, S. Bryant, J. Korhonen.

Date: October 2021

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9056

This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet-switched network.

RFC 9057 Email Author Header Field

Authors: D. Crocker.

Date: June 2021

Formats: txt html json pdf xml

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9057

Internet mail defines the From: header field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message on the author's behalf. The Sender: field is optional if it has the same information as the From: field.This was not a problem until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field to circumvent mail rejection caused by those protections. In effect, the From: field has become dominated by its role as a handling identifier.
The current specification augments the altered use of the From: field by specifying the Author: field, which ensures identification of the original author of the message and is not subject to modification byMediators. This document is published as an Experimental RFC to assess community interest, functional efficacy, and technical adequacy.

RFC 9058 Multilinear Galois Mode (MGM)

Authors: S. Smyshlyaev, Ed., V. Nozdrunov, V. Shishkin, E. Griboedova.

Date: June 2021

Formats: txt json pdf html xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9058

Multilinear Galois Mode (MGM) is an Authenticated Encryption withAssociated Data (AEAD) block cipher mode based on the Encrypt-then-MAC (EtM) principle. MGM is defined for use with 64-bit and 128-bit block ciphers.
MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g., TLS 1.3 andIPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher.

RFC 9059 Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)

Authors: R. Gandhi, Ed., C. Barth, B. Wen.

Date: June 2021

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9059

This document defines Path Computation Element Communication Protocol(PCEP) extensions for grouping two unidirectional MPLS-TE LabelSwitched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP. These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiatedLSPs or using a stateless PCE. The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling.

RFC 9060 Secure Telephone Identity Revisited (STIR) Certificate Delegation

Authors: J. Peterson.

Date: September 2021

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9060

The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing.This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR.

RFC 9061 A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)

Authors: R. Marin-Lopez, G. Lopez-Millan, F. Pereniguez-Garcia.

Date: July 2021

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9061

This document describes how to provide IPsec-based flow protection(integrity and confidentiality) by means of an Interface to NetworkSecurity Function (I2NSF) Controller. It considers two main well- known scenarios in IPsec: gateway-to-gateway and host-to-host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (IPsec SAs) from an I2NSFController to one or several flow-based Network Security Functions(NSFs) that rely on IPsec to protect data traffic.
This document focuses on the I2NSF NSF-Facing Interface by providingYANG data models for configuring the IPsec databases, namely SecurityPolicy Database (SPD), Security Association Database (SAD), PeerAuthorization Database (PAD), and Internet Key Exchange Version 2(IKEv2). This allows IPsec SA establishment with minimal intervention by the network administrator. This document defines three YANG modules, but it does not define any new protocol.

RFC 9062 Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM)

Authors: S. Salam, A. Sajassi, S. Aldrin, J. Drake, D. Eastlake 3rd.

Date: June 2021

Formats: txt html json pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9062

This document specifies the requirements and reference framework forEthernet VPN (EVPN) Operations, Administration, and Maintenance(OAM). The requirements cover the OAM aspects of EVPN and ProviderBackbone Bridge EVPN (PBB-EVPN). The framework defines the layeredOAM model encompassing the EVPN service layer, network layer, underlying Packet Switched Network (PSN) transport layer, and link layer but focuses on the service and network layers.

RFC 9063 Host Identity Protocol Architecture

Authors: R. Moskowitz, Ed., M. Komu.

Date: July 2021

Formats: txt html pdf json xml

Obsoletes: RFC 4423

Status: INFORMATIONAL

DOI: 10.17487/RFC 9063

This memo describes the Host Identity (HI) namespace, which provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming, and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of theHI namespace in the protocols are defined.
This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The SecurityConsiderations section also describes measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers, and trust on first use. This document incorporates lessons learned from the implementations of RFC 7401 and goes further to explain how HIP works as a secure signaling channel.

RFC 9064 Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols

Authors: D. Oran.

Date: June 2021

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9064

This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (NDN), which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve transport- and higher- layer QoS objectives. It explicitly excludes any discussion ofQuality of Experience (QoE), which can only be assessed and controlled at the application layer or above.
This document is not a product of the IRTF Information-CentricNetworking Research Group (ICNRG) but has been through formal LastCall and has the support of the participants in the research group for publication as an individual submission.

RFC 9065 Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols

Authors: G. Fairhurst, C. Perkins.

Date: July 2021

Formats: txt json html pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9065

To protect user data and privacy, Internet transport protocols have supported payload encryption and authentication for some time. Such encryption and authentication are now also starting to be applied to the transport protocol headers. This helps avoid transport protocol ossification by middleboxes, mitigate attacks against the transport protocol, and protect metadata about the communication. Current operational practice in some networks inspect transport header information within the network, but this is no longer possible when those transport headers are encrypted.
This document discusses the possible impact when network traffic uses a protocol with an encrypted transport header. It suggests issues to consider when designing new transport protocols or features.

RFC 9066 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home

Authors: T. Reddy.K, M. Boucadair, Ed., J. Shallow.

Date: December 2021

Formats: txt xml html pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9066

This document specifies the Denial-of-Service Open Threat Signaling(DOTS) signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client and to receive attack traffic information from the Call Home DOTS client.The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s).
The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to blockDDoS attack traffic closer to the source(s) of a DDoS attack.

RFC 9067 A YANG Data Model for Routing Policy

Authors: Y. Qu, J. Tantsura, A. Lindem, X. Liu.

Date: October 2021

Formats: txt xml html pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9067

This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way. The model provides a generic routing policy framework that can be extended for specific routing protocols using the YANG 'augment' mechanism.

RFC 9068 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Authors: V. Bertocci.

Date: October 2021

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9068

This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.

RFC 9069 Support for Local RIB in the BGP Monitoring Protocol (BMP)

Authors: T. Evens, S. Bayraktar, M. Bhardwaj, P. Lucente.

Date: February 2022

Formats: txt json xml pdf html

Updates: RFC 7854

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9069

The BGP Monitoring Protocol (BMP) defines access to local RoutingInformation Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process.

RFC 9070 YANG Data Model for MPLS LDP

Authors: K. Raza, Ed., R. Asati, X. Liu, S. Esale, X. Chen, H. Shah.

Date: March 2022

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9070

This document describes a YANG data model for the Multiprotocol LabelSwitching (MPLS) Label Distribution Protocol (LDP). The model also serves as the base model to define the Multipoint LDP (mLDP) model.
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA).

RFC 9071 RTP-Mixer Formatting of Multiparty Real-Time Text

Authors: G. Hellström.

Date: July 2021

Formats: txt pdf json xml html

Updates: RFC 4103

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9071

This document provides enhancements of real-time text (as specified in RFC 4103) suitable for mixing in a centralized conference model, enabling source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multiparty real-time text session. The specified mechanism builds on the standard use of the Contributing Source (CSRC) list in the Real-time TransportProtocol (RTP) packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two-party sessions.
Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP- mixer model. The RTP-mixer model was selected to be used for the fully specified solution in this document because it can be applied to a wide range of existing RTP implementations.
A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multiparty-coded real-time text stream using the RTP-mixer method. The capability is indicated by the use of a Session Description Protocol (SDP) (RFC 8866) media attribute, "rtt-mixer".
This document updates RFC 4103 ("RTP Payload for Text Conversation").
A specification for how a mixer can format text for the case when the endpoint is not multiparty aware is also provided.

RFC 9072 Extended Optional Parameters Length for BGP OPEN Message

Authors: E. Chen, J. Scudder.

Date: July 2021

Formats: txt html xml pdf json

Updates: RFC 4271

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9072

The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concerns about this limitation.
This document updates RFC 4271 by extending, in a backward-compatible manner, the length of the Optional Parameters in a BGP OPEN message.The Parameter Length field of individual Optional Parameters is also extended.

RFC 9073 Event Publishing Extensions to iCalendar

Authors: M. Douglass.

Date: August 2021

Formats: txt html json xml pdf

Updates: RFC 5545

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9073

This specification updates RFC 5545 by introducing a number of new iCalendar properties and components that are of particular use for event publishers and in social networking.
This specification also defines a new "STRUCTURED-DATA" property for iCalendar (RFC 5545) to allow for data that is directly pertinent to an event or task to be included with the calendar data.

RFC 9074 "VALARM" Extensions for iCalendar

Authors: C. Daboo, K. Murchison, Ed..

Date: August 2021

Formats: txt json xml html pdf

Updates: RFC 5545

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9074

This document defines a set of extensions to the iCalendar "VALARM" component to enhance the use of alarms and improve interoperability between clients and servers.
This document updates RFC 5545.

RFC 9075 Report from the IAB COVID-19 Network Impacts Workshop 2020

Authors: J. Arkko, S. Farrell, M. Kühlewind, C. Perkins.

Date: July 2021

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9075

The Coronavirus disease (COVID-19) pandemic caused changes inInternet user behavior, particularly during the introduction of initial quarantine and work-from-home arrangements. These behavior changes drove changes in Internet traffic.
The Internet Architecture Board (IAB) held a workshop to discuss network impacts of the pandemic on November 9-13, 2020. The workshop was held to convene interested researchers, network operators, network management experts, and Internet technologists to share their experiences. The meeting was held online given the ongoing travel and contact restrictions at that time.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 9076 DNS Privacy Considerations

Authors: T. Wicinski, Ed..

Date: July 2021

Formats: txt html pdf xml json

Obsoletes: RFC 7626

Status: INFORMATIONAL

DOI: 10.17487/RFC 9076

This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626.

RFC 9077 NSEC and NSEC3: TTLs and Aggressive Use

Authors: P. van Dijk.

Date: July 2021

Formats: txt pdf xml html json

Updates: RFC 4034, RFC 4035, RFC 5155, RFC 8198

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9077

Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC and NSEC3 TTL to correct that situation. This document updates RFCs 4034, 4035, 5155, and 8198.

RFC 9078 Reaction: Indicating Summary Reaction to a Message

Authors: D. Crocker, R. Signes, N. Freed.

Date: August 2021

Formats: txt json pdf xml html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9078

The popularity of social media has led to user comfort with easily signaling basic reactions to an author's posting, such as with a'thumbs up' or 'smiley' graphic. This specification permits a similar facility for Internet Mail.

RFC 9079 Source-Specific Routing in the Babel Routing Protocol

Authors: M. Boutier, J. Chroboczek.

Date: August 2021

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9079

Source-specific routing, also known as Source Address DependentRouting (SADR), is an extension to traditional next-hop routing where packets are forwarded according to both their destination address and their source address. This document describes an extension for source-specific routing to the Babel routing protocol.

RFC 9080 Homenet Profile of the Babel Routing Protocol

Authors: J. Chroboczek.

Date: August 2021

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9080

This document defines the exact subset of the Babel routing protocol and its extensions that is required by an implementation of theHomenet protocol suite, as well as the interactions between the HomeNetworking Control Protocol (HNCP) and Babel.

RFC 9081 Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes

Authors: Z. Zhang, L. Giuliano.

Date: July 2021

Formats: txt json pdf xml html

Updates: RFC 6514

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9081

This document specifies the procedures for interoperation betweenMulticast Virtual Private Network (MVPN) Source-Active (SA) routes and customer Multicast Source Discovery Protocol (MSDP) SA routes, which is useful for MVPN provider networks offering services to customers with an existing MSDP infrastructure. Without the procedures described in this document, VPN-specific MSDP sessions are required among the Provider Edge (PE) routers that are customer MSDP peers. This document updates RFC 6514.

RFC 9082 Registration Data Access Protocol (RDAP) Query Format

Authors: S. Hollenbeck, A. Newton.

Date: June 2021

Formats: txt xml pdf html json

Obsoletes: RFC 7482

Also: STD 0095

Status: INTERNET STANDARD

DOI: 10.17487/RFC 9082

This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries(including both Regional Internet Registries (RIRs) and Domain NameRegistries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration DataAccess Protocol (RDAP). This document obsoletes RFC 7482.

RFC 9083 JSON Responses for the Registration Data Access Protocol (RDAP)

Authors: S. Hollenbeck, A. Newton.

Date: June 2021

Formats: txt html xml pdf json

Obsoletes: RFC 7483

Also: STD 0095

Status: INTERNET STANDARD

DOI: 10.17487/RFC 9083

This document describes JSON data structures representing registration information maintained by Regional Internet Registries(RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483.

RFC 9084 OSPF Prefix Originator Extensions

Authors: A. Wang, A. Lindem, J. Dong, P. Psenak, K. Talaulikar, Ed..

Date: August 2021

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9084

This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. These extensions do not change the core OSPF route computation functionality but provide useful information for network analysis, troubleshooting, and use cases like traffic engineering.

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 9086 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering

Authors: S. Previdi, K. Talaulikar, Ed., C. Filsfils, K. Patel, S. Ray, J. Dong.

Date: August 2021

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9086

A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per- flow state only at the ingress node of the SR domain.
This document describes an extension to Border Gateway Protocol -Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP EgressPeer Engineering (EPE) policies and strategies can be computed based on Segment Routing.

RFC 9087 Segment Routing Centralized BGP Egress Peer Engineering

Authors: C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., E. Aries, D. Afanasiev.

Date: August 2021

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9087

Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain.
The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols.
This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-basedBGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain.

RFC 9088 Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS

Authors: X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci.

Date: August 2021

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9088

Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress LabelSwitching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities usingIS-IS and Border Gateway Protocol - Link State (BGP-LS).

RFC 9089 Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF

Authors: X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci.

Date: August 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9089

Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress LabelSwitching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities usingOSPFv2 and OSPFv3, and Border Gateway Protocol - Link State (BGP-LS).

RFC 9090 Concise Binary Object Representation (CBOR) Tags for Object Identifiers

Authors: C. Bormann.

Date: July 2021

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9090

The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined.

RFC 9091 Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains

Authors: S. Kitterman, T. Wicinski, Ed..

Date: July 2021

Formats: txt json xml pdf html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9091

Domain-based Message Authentication, Reporting, and Conformance(DMARC), defined in RFC 7489, permits a domain-controlling organization to express domain-level policies and preferences for message validation, disposition, and reporting, which a mail- receiving organization can use to improve mail handling.
DMARC distinguishes the portion of a name that is a Public SuffixDomain (PSD), below which Organizational Domain names are created.The basic DMARC capability allows Organizational Domains to specify policies that apply to their subdomains, but it does not give that capability to PSDs. This document describes an extension to DMARC to fully enable DMARC functionality for PSDs.
Some implementations of DMARC consider a PSD to be ineligible forDMARC enforcement. This specification addresses that case.

RFC 9092 Finding and Using Geofeed Data

Authors: R. Bush, M. Candela, W. Kumari, R. Housley.

Date: July 2021

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9092

This document specifies how to augment the Routing PolicySpecification Language inetnum: class to refer specifically to geofeed data comma-separated values (CSV) files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed data CSV files.

RFC 9093 A YANG Data Model for Layer 0 Types

Authors: H. Zheng, Y. Lee, A. Guo, V. Lopez, D. King.

Date: August 2021

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9093

This document defines a collection of common data types and groupings in the YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Layer 0 optical Traffic Engineering (TE) configuration and state capabilities such as Wavelength Switched Optical Networks (WSONs) and flexi-gridDense Wavelength Division Multiplexing (DWDM) networks.

RFC 9094 A YANG Data Model for Wavelength Switched Optical Networks (WSONs)

Authors: H. Zheng, Y. Lee, A. Guo, V. Lopez, D. King.

Date: August 2021

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9094

This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in Wavelength SwitchedOptical Networks (WSONs). The YANG data model defined in this document conforms to the Network Management Datastore Architecture(NMDA).

RFC 9095 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration

Authors: J. Yao, L. Zhou, H. Li, N. Kong, J. Xie.

Date: July 2021

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9095

This document describes an extension of Extensible ProvisioningProtocol (EPP) domain name mapping for the provisioning and management of strict bundling registration of domain names.Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of bundled domain names. This is a nonstandard proprietary extension.

RFC 9096 Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events

Authors: F. Gont, J. Žorž, R. Patterson, B. Volz.

Date: August 2021

Formats: txt html xml pdf json

Updates: RFC 7084

Also: BCP 0234

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9096

This document specifies improvements to Customer Edge routers that help mitigate the problems that may arise when network configuration information becomes invalid without any explicit signaling of that condition to the local nodes. This document updates RFC 7084.

RFC 9097 Metrics and Methods for One-Way IP Capacity

Authors: A. Morton, R. Geib, L. Ciavattone.

Date: November 2021

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9097

This memo revisits the problem of Network Capacity Metrics first examined in RFC 5136. This memo specifies a more practical MaximumIP-Layer Capacity Metric definition catering to measurement and outlines the corresponding Methods of Measurement.

RFC 9098 Operational Implications of IPv6 Packets with Extension Headers

Authors: F. Gont, N. Hilliard, G. Doering, W. Kumari, G. Huston, W. Liu.

Date: September 2021

Formats: txt json xml html pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9098

This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.

RFC 9099 Operational Security Considerations for IPv6 Networks

Authors: É. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey.

Date: August 2021

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9099

Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices.
This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks.

RFC 9100 Sensor Measurement Lists (SenML) Features and Versions

Authors: C. Bormann.

Date: August 2021

Formats: txt json pdf xml html

Updates: RFC 8428

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9100

This short document updates RFC 8428, "Sensor Measurement Lists(SenML)", by specifying the use of independently selectable "SenMLFeatures" and mapping them to SenML version numbers.

RFC 9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)

Authors: N. Sakimura, J. Bradley, M. Jones.

Date: August 2021

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9101

The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.
This document introduces the ability to send request parameters in aJSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption(JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained.The request can be sent by value or by reference.

RFC 9102 TLS DNSSEC Chain Extension

Authors: V. Dukhovni, S. Huque, W. Toorop, P. Wouters, M. Shore.

Date: August 2021

Formats: txt html xml pdf json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9102

This document describes an experimental TLS extension for the in-band transport of the complete set of records that can be validated byDNSSEC and that are needed to perform DNS-Based Authentication ofNamed Entities (DANE) of a TLS server. This extension obviates the need to perform separate, out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a denial- of-existence proof that can be validated.
This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations.

RFC 9103 DNS Zone Transfer over TLS

Authors: W. Toorop, S. Dickinson, S. Sahib, P. Aras, A. Mankin.

Date: August 2021

Formats: txt xml html pdf json

Updates: RFC 1995, RFC 5936, RFC 7766

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9103

DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature(TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC7766 with respect to the recommended number of connections between a client and server for each transport.

RFC 9104 Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS)

Authors: J. Tantsura, Z. Wang, Q. Wu, K. Talaulikar.

Date: August 2021

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9104

Administrative groups are link attributes used for traffic engineering. This document defines an extension to the BorderGateway Protocol - Link State (BGP-LS) for advertisement of extended administrative groups (EAGs).

RFC 9105 A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)

Authors: B. Wu, Ed., G. Zheng, M. Wang, Ed..

Date: August 2021

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9105

This document defines a Terminal Access Controller Access-ControlSystem Plus (TACACS+) client YANG module that augments the SystemManagement data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Though being a standard module, this module does not endorse the security mechanisms of the TACACS+ protocol (RFC8907), and TACACS+ MUST be used within a secure deployment.
The YANG module in this document conforms to the Network ManagementDatastore Architecture (NMDA) defined in RFC 8342.

RFC 9106 Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications

Authors: A. Biryukov, D. Dinu, D. Khovratovich, S. Josefsson.

Date: September 2021

Formats: txt html json pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9106

This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer- oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

RFC 9107 BGP Optimal Route Reflection (BGP ORR)

Authors: R. Raszuk, Ed., B. Decraene, Ed., C. Cassar, E. Åman, K. Wang.

Date: August 2021

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9107

This document defines an extension to BGP route reflectors. On route reflectors, BGP route selection is modified in order to choose the best route from the standpoint of their clients, rather than from the standpoint of the route reflectors themselves. Depending on the scaling and precision requirements, route selection can be specific for one client, common for a set of clients, or common for all clients of a route reflector. This solution is particularly applicable in deployments using centralized route reflectors, where choosing the best route based on the route reflector's IGP location is suboptimal. This facilitates, for example, a "best exit point" policy ("hot potato routing").
The solution relies upon all route reflectors learning all paths that are eligible for consideration. BGP route selection is performed in the route reflectors based on the IGP cost from configured locations in the link-state IGP.

RFC 9108 YANG Types for DNS Classes and Resource Record Types

Authors: L. Lhotka, P. Špaček.

Date: September 2021

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9108

This document introduces the YANG module "iana-dns-class-rr-type", which contains derived types reflecting two IANA registries: DNSCLASSes and Resource Record (RR) TYPEs. These YANG types are intended as the minimum basis for future data modeling work.

RFC 9109 Network Time Protocol Version 4: Port Randomization

Authors: F. Gont, G. Gont, M. Lichvar.

Date: August 2021

Formats: txt json pdf html xml

Updates: RFC 5905

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9109

The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port.However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks. This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required.

RFC 9110 HTTP Semantics

Authors: R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed..

Date: June 2022

Formats: txt json xml html pdf

Obsoletes: RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694

Updates: RFC 3864

Also: STD 0097

Status: INTERNET STANDARD

DOI: 10.17487/RFC 9110

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and"https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232,7233, 7235, 7538, 7615, 7694, and portions of 7230.

RFC 9111 HTTP Caching

Authors: R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed..

Date: June 2022

Formats: txt json html xml pdf

Obsoletes: RFC 7234

Also: STD 0098

Status: INTERNET STANDARD

DOI: 10.17487/RFC 9111

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.
This document obsoletes RFC 7234.

RFC 9112 HTTP/1.1

Authors: R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed..

Date: June 2022

Formats: txt html pdf xml json

Obsoletes: RFC 7230

Also: STD 0099

Status: INTERNET STANDARD

DOI: 10.17487/RFC 9112

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.
This document obsoletes portions of RFC 7230.

RFC 9113 HTTP/2

Authors: M. Thomson, Ed., C. Benfield, Ed..

Date: June 2022

Formats: txt pdf xml html json

Obsoletes: RFC 7540, RFC 8740

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9113

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 latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.
This document obsoletes RFCs 7540 and 8740.

RFC 9114 HTTP/3

Authors: M. Bishop, Ed..

Date: June 2022

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9114

The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.

RFC 9115 An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates

Authors: Y. Sheffer, D. López, A. Pastor Perales, T. Fossati.

Date: September 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9115

This document defines a profile of the Automatic CertificateManagement Environment (ACME) protocol by which the holder of an identifier (e.g., a domain name) can allow a third party to obtain anX.509 certificate such that the certificate subject is the delegated identifier while the certified public key corresponds to a private key controlled by the third party. A primary use case is that of aContent Delivery Network (CDN), the third party, terminating TLS sessions on behalf of a content provider (the holder of a domain name). The presented mechanism allows the holder of the identifier to retain control over the delegation and revoke it at any time.Importantly, this mechanism does not require any modification to the deployed TLS clients and servers.

RFC 9116 A File Format to Aid in Security Vulnerability Disclosure

Authors: E. Foudil, Y. Shafranovich.

Date: April 2022

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9116

When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities.

RFC 9117 Revised Validation Procedure for BGP Flow Specifications

Authors: J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. Mohapatra.

Date: August 2021

Formats: txt html json xml pdf

Updates: RFC 8955

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9117

This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications as specified in RFC 8955 requires that the originator of the Flow Specification match the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an Internal Border GatewayProtocol (iBGP) received route, the originator is typically a border router within the same autonomous system (AS). The objective is to allow only BGP speakers within the data forwarding path to originateBGP Flow Specifications. Sometimes it is desirable to originate theBGP Flow Specification from any place within the autonomous system itself, for example, from a centralized BGP route controller.However, the validation procedure described in RFC 8955 will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises the AS_PATH validation rules so Flow Specifications received from an ExternalBorder Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP route server.
This document updates the validation procedure in RFC 8955.

RFC 9118 Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates

Authors: R. Housley.

Date: August 2021

Formats: txt json xml pdf html

Updates: RFC 8226

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9118

RFC 8226 specifies the use of certificates for Secure TelephoneIdentity Credentials; these certificates are often called "SecureTelephone Identity Revisited (STIR) Certificates". RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT), as defined in RFC 8225. If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT. This document updates RFC 8226; it provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims. The enhanced extension can also provide a list of claims that are not allowed to be included in the PASSporT.

RFC 9119 Multicast Considerations over IEEE 802 Wireless Media

Authors: C. Perkins, M. McBride, D. Stanley, W. Kumari, JC. Zúñiga.

Date: October 2021

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9119

Well-known issues with multicast have prevented the deployment of multicast in 802.11 (Wi-Fi) and other local-area wireless environments. This document describes the known limitations of wireless (primarily 802.11) Layer 2 multicast. Also described are certain multicast enhancement features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some operational choices that can be made to improve the performance of the network. Finally, some recommendations are provided about the usage and combination of these features and operational choices.

RFC 9120 Nameservers for the Address and Routing Parameter Area ("arpa") Domain

Authors: K. Davies, J. Arkko.

Date: October 2021

Formats: txt pdf json xml html

Updates: RFC 3172

Status: INFORMATIONAL

DOI: 10.17487/RFC 9120

This document describes revisions to operational practices to separate the function of the "arpa" top-level domain in the DNS from its historical operation alongside the DNS root zone.

RFC 9121 Deprecating Infrastructure "int" Domains

Authors: K. Davies, A. Baber.

Date: April 2023

Formats: txt pdf json xml html

Obsoletes: RFC 1528

Updates: RFC 1706

Status: INFORMATIONAL

DOI: 10.17487/RFC 9121

This document deprecates the use of any "int" domain names that were designated for infrastructure purposes by the IETF, and it identifies them for removal from the "int" top-level domain. Any implementations that involve these domains are now deprecated. This document also changes the status of RFC 1528 and RFC 1706 toHistoric.

RFC 9122 IANA Registry for Sieve Actions

Authors: A. Melnikov, K. Murchison.

Date: June 2023

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9122

The Sieve Email Filtering Language (RFC 5228) is a popular email filtering language used upon final mail delivery. This document creates a registry for Sieve actions to help developers and Sieve extension writers track interactions between different extensions.

RFC 9124 A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices

Authors: B. Moran, H. Tschofenig, H. Birkholz.

Date: January 2022

Formats: txt json xml html pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9124

Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality.
One component of such a firmware update is a concise and machine- processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest.

RFC 9125 Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing

Authors: A. Farrel, J. Drake, E. Rosen, K. Patel, L. Jalil.

Date: August 2021

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9125

Data centers are attached to the Internet or a backbone network by gateway routers. One data center typically has more than one gateway for commercial, load-balancing, and resiliency reasons. Other sites, such as access networks, also need to be connected across backbone networks through gateways.
This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow data center gateway routers to advertise routes to the prefixes reachable in the site, including advertising them on behalf of other gateways at the same site. This allows segment routing to be used to identify multiple paths across the Internet or backbone network between different gateways. The paths can be selected for load-balancing, resilience, and quality purposes.

RFC 9126 OAuth 2.0 Pushed Authorization Requests

Authors: T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. Skokan.

Date: September 2021

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9126

This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.

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 9128 YANG Data Model for Protocol Independent Multicast (PIM)

Authors: X. Liu, P. McAllister, A. Peter, M. Sivakumar, Y. Liu, F. Hu.

Date: October 2022

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9128

This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM).The model covers the PIM protocol configuration, operational state, and event notifications data.

RFC 9129 YANG Data Model for the OSPF Protocol

Authors: D. Yeung, Y. Qu, Z. Zhang, I. Chen, A. Lindem.

Date: October 2022

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9129

This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC7950 and conforms to the Network Management Datastore Architecture(NMDA) as described in RFC 8342.

RFC 9130 YANG Data Model for the IS-IS Protocol

Authors: S. Litkowski, Ed., D. Yeung, A. Lindem, J. Zhang, L. Lhotka.

Date: October 2022

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9130

This document defines a YANG data model that can be used to configure and manage the IS-IS protocol on network elements.

RFC 9131 Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers

Authors: J. Linkova.

Date: October 2021

Formats: txt json xml pdf html

Updates: RFC 4861

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9131

Neighbor Discovery (RFC 4861) is used by IPv6 nodes to determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information. This document updates RFC 4861 to allow routers to proactively create a Neighbor Cache entry when a newIPv6 address is assigned to a node. It also updates RFC 4861 and recommends that nodes send unsolicited Neighbor Advertisements upon assigning a new IPv6 address. These changes will minimize the delay and packet loss when a node initiates connections to an off-link destination from a new IPv6 address.

RFC 9132 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification

Authors: M. Boucadair, Ed., J. Shallow, T. Reddy.K.

Date: September 2021

Formats: txt html pdf json xml

Obsoletes: RFC 8782

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9132

This document specifies the Distributed Denial-of-Service Open ThreatSignaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.
This document obsoletes RFC 8782.

RFC 9133 Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel

Authors: K. Nishizuka, M. Boucadair, T. Reddy.K, T. Nagata.

Date: September 2021

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9133

This document specifies an extension to the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol so thatDOTS clients can control their filtering rules when an attack mitigation is active.
Particularly, this extension allows a DOTS client to activate or deactivate existing filtering rules during a Distributed Denial-of-Service (DDoS) attack. The characterization of these filtering rules is conveyed by a DOTS client during an 'idle' time (i.e., no mitigation is active) by means of the DOTS data channel protocol.

RFC 9134 RTP Payload Format for ISO/IEC 21122 (JPEG XS)

Authors: T. Bruylants, A. Descampe, C. Damman, T. Richter.

Date: October 2021

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9134

This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting video encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and video frame rates while offering visually lossless quality, reduced power consumption, and encoding-decoding latency confined to a fraction of a video frame.

RFC 9135 Integrated Routing and Bridging in Ethernet VPN (EVPN)

Authors: A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan.

Date: October 2021

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9135

Ethernet VPN (EVPN) provides an extensible and flexible multihomingVPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and end devices that can be physical or virtual.However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and end devices while maintaining the multihoming capabilities ofEVPN. This document describes an Integrated Routing and Bridging(IRB) solution based on EVPN to address such requirements.

RFC 9136 IP Prefix Advertisement in Ethernet VPN (EVPN)

Authors: J. Rabadan, Ed., W. Henderickx, J. Drake, W. Lin, A. Sajassi.

Date: October 2021

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9136

The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in anMPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network.In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used.

RFC 9137 Considerations for Cancellation of IETF Meetings

Authors: M. Duke.

Date: October 2021

Formats: txt xml html pdf json

Also: BCP 0226

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9137

The IETF ordinarily holds three in-person meetings per year to discuss issues and advance the Internet. However, various events can make a planned in-person meeting infeasible. This document provides criteria to aid the IETF Administration LLC (IETF LLC), the InternetEngineering Steering Group (IESG), and the Chair of the InternetResearch Task Force (IRTF) in deciding to relocate, virtualize, postpone, or cancel an in-person IETF meeting.

RFC 9138 Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)

Authors: J. Hong, T. You, L. Dong, C. Westphal, B. Ohlman.

Date: December 2021

Formats: txt xml json pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9138

This document provides the functionalities and design considerations for a Name Resolution Service (NRS) in Information-Centric Networking(ICN). The purpose of an NRS in ICN is to translate an object name into some other information such as a locator, another name, etc. in order to forward the object request. This document is a product of the Information-Centric Networking Research Group (ICNRG).

RFC 9139 Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)

Authors: C. Gündoğan, T. Schmidt, M. Wählisch, C. Scherb, C. Marxer, C. Tschudin.

Date: November 2021

Formats: txt xml pdf json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9139

This document defines a convergence layer for Content-CentricNetworking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN.Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links.Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide states local to the LoWPAN and replace names in Data packets by short local identifiers.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG).

RFC 9140 Nimble Out-of-Band Authentication for EAP (EAP-NOOB)

Authors: T. Aura, M. Sethi, A. Peltonen.

Date: December 2021

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9140

The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no preconfigured authentication credentials. The method makes use of a user-assisted, one-directional, out-of-band (OOB) message between the peer device and authentication server to authenticate the in-band key exchange.The device must have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking light, that can send or receive dynamically generated messages of tens of bytes in length.

RFC 9141 Updating References to the IETF FTP Service

Authors: R. Danyliw.

Date: November 2021

Formats: txt html pdf xml json

Updates: RFC 2077, RFC 2418, RFC 2648, RFC 2954, RFC 2955, RFC 3020, RFC 3083, RFC 3201, RFC 3202, RFC 3295, RFC 3684, RFC 3962, RFC 3970, RFC 4036, RFC 4131, RFC 4251, RFC 4323, RFC 4546, RFC 4547, RFC 4639, RFC 4682, RFC 5098, RFC 5428, RFC 6756, RFC 7241

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9141

The IETF FTP service running at ftp.ietf.org, ops.ietf.org, and ietf.org will be retired. A number of published RFCs in the IETF andIAB streams include URIs that reference this FTP service. To ensure that the materials referenced using the IETF FTP service can still be found, this document updates the FTP-based references in these affected documents with HTTPS URIs.

RFC 9142 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)

Authors: M. Baushke.

Date: January 2022

Formats: txt xml pdf json html

Updates: RFC 4250, RFC 4253, RFC 4432, RFC 4462

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9142

This document updates the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. It updates RFCs 4250, 4253, 4432, and 4462.

RFC 9143 Negotiating Media Multiplexing Using the Session Description Protocol (SDP)

Authors: C. Holmberg, H. Alvestrand, C. Jennings.

Date: February 2022

Formats: txt json xml pdf html

Obsoletes: RFC 8843

Updates: RFC 3264, RFC 5888, RFC 7941

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9143

This specification defines a new Session Description Protocol (SDP)Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and the media is referred to as "bundled media". The "m=" sections that use the BUNDLE transport form a BUNDLE group.
This specification defines a new RTP Control Protocol (RTCP) SourceDescription (SDES) item and a new RTP header extension.
This specification updates RFCs 3264, 5888, and 7941.
This specification obsoletes RFC 8843.

RFC 9144 Comparison of Network Management Datastore Architecture (NMDA) Datastores

Authors: A. Clemm, Y. Qu, J. Tantsura, A. Bierman.

Date: December 2021

Formats: txt xml html pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9144

This document defines a Remote Procedure Call (RPC) operation to compare management datastores that comply with the Network ManagementDatastore Architecture (NMDA).

RFC 9145 Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers

Authors: M. Boucadair, T. Reddy.K, D. Wing.

Date: December 2021

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9145

This specification presents an optional method to add integrity protection directly to the Network Service Header (NSH) used forService Function Chaining (SFC). Also, this specification allows for the encryption of sensitive metadata (MD) that is carried in the NSH.

RFC 9146 Connection Identifier for DTLS 1.2

Authors: E. Rescorla, Ed., H. Tschofenig, Ed., T. Fossati, A. Kraus.

Date: March 2022

Formats: txt json html pdf xml

Updates: RFC 6347

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9146

This document specifies the Connection ID (CID) construct for theDatagram Transport Layer Security (DTLS) protocol version 1.2.
A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session, then the receiver will be unable to locate the correct security context.
The new ciphertext record format with the CID also provides content type encryption and record layer padding.
This document updates RFC 6347.

RFC 9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3

Authors: E. Rescorla, H. Tschofenig, N. Modadugu.

Date: April 2022

Formats: txt json pdf xml html

Obsoletes: RFC 6347

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9147

This document specifies version 1.3 of the Datagram Transport LayerSecurity (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
The DTLS 1.3 protocol is based on the Transport Layer Security (TLS)1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.
This document obsoletes RFC 6347.

RFC 9148 EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol

Authors: P. van der Stok, P. Kampanakis, M. Richardson, S. Raza.

Date: April 2022

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9148

Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.

RFC 9149 TLS Ticket Requests

Authors: T. Pauly, D. Schinazi, C.A. Wood.

Date: April 2022

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9149

TLS session tickets enable stateless connection resumption for clients without server-side, per-client state. Servers vend an arbitrary number of session tickets to clients, at their discretion, upon connection establishment. Clients store and use tickets when resuming future connections. This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections. This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste while simultaneously priming clients for future connection attempts.

RFC 9150 TLS 1.3 Authentication and Integrity-Only Cipher Suites

Authors: N. Cam-Winget, J. Visoky.

Date: April 2022

Formats: txt html json xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9150

This document defines the use of cipher suites for TLS 1.3 based onHashed Message Authentication Code (HMAC). Using these cipher suites provides server and, optionally, mutual authentication and data authenticity, but not data confidentiality. Cipher suites with these properties are not of general applicability, but there are use cases, specifically in Internet of Things (IoT) and constrained environments, that do not require confidentiality of exchanged messages while still requiring integrity protection, server authentication, and optional client authentication. This document gives examples of such use cases, with the caveat that prior to using these integrity-only cipher suites, a threat model for the situation at hand is needed, and a threat analysis must be performed within that model to determine whether the use of integrity-only cipher suites is appropriate. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced- security mechanism that provides authentication and message integrity without supporting confidentiality.

RFC 9151 Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3

Authors: D. Cooley.

Date: April 2022

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9151

This document defines a base profile for TLS protocol versions 1.2 and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the US Commercial National Security Algorithm (CNSA) Suite.
The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that use TLS orDTLS. It is also appropriate for all other US Government systems that process high-value information.
The profile is made publicly available here for use by developers and operators of these and any other system deployments.

RFC 9152 Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients

Authors: M. Jenkins, S. Turner.

Date: April 2022

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9152

This document specifies protocol interfaces profiled by the UnitedStates National Security Agency (NSA) for National Security System(NSS) servers that provide public key certificates, CertificateRevocation Lists (CRLs), and symmetric keys to NSS clients. Servers that support these interfaces are referred to as Secure ObjectDelivery Protocol (SODP) servers. The intended audience for this profile comprises developers of client devices that will obtain key management services from NSA-operated SODP servers. Interfaces supported by SODP servers include Enrollment over Secure Transport(EST) and its extensions as well as Certificate Management over CMS(CMC).
This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (SP800-59). It is also appropriate for other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

RFC 9153 Drone Remote Identification Protocol (DRIP) Requirements and Terminology

Authors: S. Card, Ed., A. Wiethuechter, R. Moskowitz, A. Gurtov.

Date: February 2022

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9153

This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) WorkingGroup. These solutions will support Unmanned Aircraft System RemoteIdentification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existingInternet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy.

RFC 9154 Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer

Authors: J. Gould, R. Wilhelm.

Date: December 2021

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9154

The Extensible Provisioning Protocol (EPP) (RFC 5730) defines the use of authorization information to authorize a transfer of an EPP object, such as a domain name, between clients that are referred to as "registrars". Object-specific, password-based authorization information (see RFCs 5731 and 5733) is commonly used but raises issues related to the security, complexity, storage, and lifetime of authentication information. This document defines an operational practice, using the EPP RFCs, that leverages the use of strong random authorization information values that are short lived, not stored by the client, and stored by the server using a cryptographic hash that provides for secure authorization information that can safely be used for object transfers.

RFC 9155 Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2

Authors: L. Velvindron, K. Moriarty, A. Ghedini.

Date: December 2021

Formats: txt html pdf xml json

Updates: RFC 5246

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9155

The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack, and this document deprecates their use in TLS 1.2 and DTLS1.2 digital signatures. However, this document does not deprecateSHA-1 with Hashed Message Authentication Code (HMAC), as used in record protection. This document updates RFC 5246.

RFC 9156 DNS Query Name Minimisation to Improve Privacy

Authors: S. Bortzmeyer, R. Dolmans, P. Hoffman.

Date: November 2021

Formats: txt json xml pdf html

Obsoletes: RFC 7816

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9156

This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816.

RFC 9157 Revised IANA Considerations for DNSSEC

Authors: P. Hoffman.

Date: December 2021

Formats: txt json xml html pdf

Updates: RFC 5155, RFC 6014, RFC 8624

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9157

This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updatesRFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for HashedAuthenticated Denial of Existence). It also updates RFCs 5155 and6014, which have requirements for DNSSEC algorithms, and updates RFC8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track.The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms.

RFC 9158 Update to the Object Identifier Registry for the PKIX Working Group

Authors: R. Housley.

Date: November 2021

Formats: txt html xml json pdf

Updates: RFC 7299

Status: INFORMATIONAL

DOI: 10.17487/RFC 9158

RFC 7299 describes the object identifiers that were assigned by thePublic Key Infrastructure using X.509 (PKIX) Working Group in an arc that was allocated by IANA (1.3.6.1.5.5.7). A small number of object identifiers that were assigned in RFC 4212 are omitted from RFC 7299, and this document updates RFC 7299 to correct that oversight.

RFC 9159 IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP)

Authors: C. Gomez, S.M. Darroudi, T. Savolainen, M. Spoerk.

Date: December 2021

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9159

RFC 7668 describes the adaptation of IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) techniques to enable IPv6 overBluetooth Low Energy (Bluetooth LE) networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links established by using the Bluetooth Internet Protocol SupportProfile (IPSP). This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.

RFC 9160 Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)

Authors: T. Graf.

Date: December 2021

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9160

This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on whichMPLS control plane protocol is used within a Segment Routing domain.In particular, this document defines five code points for the IPFIX mplsTopLabelType Information Element for Path Computation Element(PCE), IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions.

RFC 9161 Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks

Authors: J. Rabadan, Ed., S. Sathappan, K. Nagaraj, G. Hankins, T. King.

Date: January 2022

Formats: txt pdf xml html json

Updates: RFC 7432

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9161

This document describes the Ethernet Virtual Private Network (EVPN)Proxy ARP/ND function augmented by the capability of the ARP/NDExtended Community. From that perspective, this document updates theEVPN specification to provide more comprehensive documentation of the operation of the Proxy ARP/ND function. The EVPN Proxy ARP/ND function and the ARP/ND Extended Community help operators of InternetExchange Points, Data Centers, and other networks deal with IPv4 andIPv6 address resolution issues associated with large BroadcastDomains by reducing and even suppressing the flooding produced by address resolution in the EVPN network.

RFC 9162 Certificate Transparency Version 2.0

Authors: B. Laurie, E. Messeri, R. Stradling.

Date: December 2021

Formats: txt json html xml pdf

Obsoletes: RFC 6962

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9162

This document describes version 2.0 of the Certificate Transparency(CT) protocol for publicly logging the existence of Transport LayerSecurity (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.
This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts.
Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

RFC 9163 Expect-CT Extension for HTTP

Authors: E. Stark.

Date: June 2022

Formats: txt json xml html pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9163

This document defines a new HTTP header field named "Expect-CT", which allows web host operators to instruct user agents (UAs) to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency (CT) deployments. Further, web host operators can use Expect-CT to ensure that if a UA that supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs.

RFC 9164 Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes

Authors: M. Richardson, C. Bormann.

Date: December 2021

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9164

This specification defines two Concise Binary Object Representation(CBOR) tags for use with IPv6 and IPv4 addresses and prefixes.

RFC 9165 Additional Control Operators for the Concise Data Definition Language (CDDL)

Authors: C. Bormann.

Date: December 2021

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9165

The Concise Data Definition Language (CDDL), standardized in RFC8610, provides "control operators" as its main language extension point.
The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: .plus, .cat, and.det for the construction of constants; .abnf/.abnfb for includingABNF (RFC 5234 and RFC 7405) in CDDL specifications; and .feature for indicating the use of a non-basic feature in an instance.

RFC 9166 A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping

Authors: H. Zhao, X. Liu, Y. Liu, A. Peter, M. Sivakumar.

Date: February 2022

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9166

This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and MulticastListener Discovery (MLD) snooping devices. The YANG module in this document conforms to the Network Management Datastore Architecture(NMDA).

RFC 9167 Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)

Authors: T. Sattler, R. Carney, J. Kolker.

Date: December 2021

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9167

This document describes an Extensible Provisioning Protocol (EPP) extension called "Registry Maintenance Notification", which is used by EPP servers to notify EPP clients and allow EPP clients to queryEPP servers regarding maintenance events.

RFC 9168 Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification

Authors: D. Dhody, A. Farrel, Z. Li.

Date: January 2022

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9168

The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path.
Traffic flows may be categorized and described using "FlowSpecifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes.
This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of.
The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the Path Computation Client (PCC). Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation.

RFC 9169 New ASN.1 Modules for the Evidence Record Syntax (ERS)

Authors: R. Housley, C. Wallace.

Date: December 2021

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9169

The Evidence Record Syntax (ERS) and the conventions for including these evidence records in the Server-based Certificate ValidationProtocol (SCVP) are expressed using ASN.1. This document offers alternative ASN.1 modules that conform to the 2002 version of ASN.1 and employ the conventions adopted in RFCs 5911, 5912, and 6268.There are no bits-on-the-wire changes to any of the formats; this is simply a change to the ASN.1 syntax.

RFC 9170 Long-Term Viability of Protocol Extension Mechanisms

Authors: M. Thomson, T. Pauly.

Date: December 2021

Formats: txt xml html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9170

The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly.

RFC 9171 Bundle Protocol Version 7

Authors: S. Burleigh, K. Fall, E. Birrane, III.

Date: January 2022

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9171

This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the InternetResearch Task Force and documented in RFC 5050.

RFC 9172 Bundle Protocol Security (BPSec)

Authors: E. Birrane, III, K. McKeever.

Date: January 2022

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9172

This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP).

RFC 9173 Default Security Contexts for Bundle Protocol Security (BPSec)

Authors: E. Birrane, III, A. White, S. Heiner.

Date: January 2022

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9173

This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security (BPSec) implementations. These security contexts are intended to be used both for testing the interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined or otherwise required for a network.

RFC 9174 Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4

Authors: B. Sipos, M. Demmer, J. Ott, S. Perreault.

Date: January 2022

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9174

This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by theConcise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles.This TCPCL version also includes security and extensibility mechanisms.

RFC 9175 Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing

Authors: C. Amsüss, J. Preuß Mattsson, G. Selander.

Date: February 2022

Formats: txt html pdf json xml

Updates: RFC 7252

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9175

This document specifies enhancements to the Constrained ApplicationProtocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non- secure reuse of Tokens to ensure response-to-request binding whenCoAP is used with a security protocol, and amplification mitigation(where the use of the Echo option is now recommended).

RFC 9176 Constrained RESTful Environments (CoRE) Resource Directory

Authors: C. Amsüss, Ed., Z. Shelby, M. Koster, C. Bormann, P. van der Stok.

Date: April 2022

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9176

In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources.Furthermore, new target attributes useful in conjunction with an RD are defined.

RFC 9177 Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission

Authors: M. Boucadair, J. Shallow.

Date: March 2022

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9177

This document specifies alternative Constrained Application Protocol(CoAP) block-wise transfer options: Q-Block1 and Q-Block2.
These options are similar to, but distinct from, the CoAP Block1 andBlock2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, theQ-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission.

RFC 9178 Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks

Authors: J. Arkko, A. Eriksson, A. Keränen.

Date: May 2022

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9178

This memo discusses the use of the Constrained Application Protocol(CoAP) in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption.

RFC 9179 A YANG Grouping for Geographic Locations

Authors: C. Hopps.

Date: February 2022

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9179

This document defines a generic geographical location YANG grouping.The geographical location grouping is intended to be used in YANG data models for specifying a location on or in reference to Earth or any other astronomical object.

RFC 9180 Hybrid Public Key Encryption

Authors: R. Barnes, K. Bhargavan, B. Lipp, C. Wood.

Date: February 2022

Formats: txt html xml json pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9180

This document describes a scheme for hybrid public key encryption(HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such asElliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

RFC 9181 A Common YANG Data Model for Layer 2 and Layer 3 VPNs

Authors: S. Barguil, O. Gonzalez de Dios, Ed., M. Boucadair, Ed., Q. Wu.

Date: February 2022

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9181

This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models.

RFC 9182 A YANG Network Data Model for Layer 3 VPNs

Authors: S. Barguil, O. Gonzalez de Dios, Ed., M. Boucadair, Ed., L. Munoz, A. Aguado.

Date: February 2022

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9182

As a complement to the Layer 3 Virtual Private Network Service Model(L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network(L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.
The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator.

RFC 9183 Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)

Authors: M. Zhang, D. Eastlake 3rd, R. Perlman, M. Cullen, H. Zhai.

Date: February 2022

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9183

A major issue in multilevel TRILL is how to manage RBridge nicknames.In this document, area border RBridges use a single nickname in bothLevel 1 and Level 2. RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames.

RFC 9184 BGP Extended Community Registries Update

Authors: C. Loibl.

Date: January 2022

Formats: txt pdf html xml json

Updates: RFC 7153, RFC 8955

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9184

This document updates several BGP Extended Community registries in order to replace the "Experimental Use" registration procedure in some entries, since their use is clearly not experimental and is thus misleading.
This document updates RFCs 7153 and 8955.

RFC 9185 DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange

Authors: P. Jones, P. Ellenbogen, N. Ohlmeier.

Date: April 2022

Formats: txt pdf xml html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9185

This document defines a protocol for tunneling DTLS traffic in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the KeyDistributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the Media Distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to theMedia Distributor.

RFC 9186 Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks

Authors: G. Mirsky, X. Ji.

Date: January 2022

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9186

This document specifies how Bidirectional Forwarding Detection (BFD) for multipoint networks can provide sub-second failover for routers that participate in Protocol Independent Multicast - Sparse Mode(PIM-SM). An extension to the PIM Hello message used to bootstrap a point-to-multipoint BFD session is also defined in this document.

RFC 9187 Sequence Number Extension for Windowed Protocols

Authors: J. Touch.

Date: January 2022

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9187

Sliding window protocols use finite sequence numbers to determine segment placement and order. These sequence number spaces wrap around and are reused during the operation of such protocols. This document describes a way to extend the size of these sequence numbers at the endpoints to avoid the impact of that wrap and reuse without transmitting additional information in the packet header. The resulting extended sequence numbers can be used at the endpoints in encryption and authentication algorithms to ensure input bit patterns do not repeat over the lifetime of a connection.

RFC 9188 Generic Multi-Access (GMA) Encapsulation Protocol

Authors: J. Zhu, S. Kanugovi.

Date: February 2022

Formats: txt html json xml pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9188

A device can be simultaneously connected to multiple networks, e.g.,Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity over these networks below the transport layer (L4) to improve the quality of experience for applications that do not have built-in multi-path capabilities. Such optimization requires additional control information, e.g., a sequence number, in each packet. This document presents a new lightweight and flexible encapsulation protocol for this need. The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP. However, this document is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations in order to experiment with the protocol.

RFC 9189 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2

Authors: S. Smyshlyaev, Ed., D. Belyavsky, E. Alekseev.

Date: March 2022

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9189

This document specifies three new cipher suites, two new signature algorithms, seven new supported groups, and two new certificate types for the Transport Layer Security (TLS) protocol version 1.2 to support the Russian cryptographic standard algorithms (called "GOST" algorithms). This document specifies a profile of TLS 1.2 with GOST algorithms so that implementers can produce interoperable implementations.
This specification facilitates implementations that aim to support the GOST algorithms. This document does not imply IETF endorsement of the cipher suites, signature algorithms, supported groups, and certificate types.

RFC 9190 EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3

Authors: J. Preuß Mattsson, M. Sethi.

Date: February 2022

Formats: txt html json pdf xml

Updates: RFC 5216

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9190

The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations ofEAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions ofTLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216.

RFC 9191 Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods

Authors: M. Sethi, J. Preuß Mattsson, S. Turner.

Date: February 2022

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9191

The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem.This document looks at this problem in detail and describes the potential solutions available.

RFC 9192 Network Service Header (NSH) Fixed-Length Context Header Allocation

Authors: T. Mizrahi, I. Yerushalmi, D. Melman, R. Browne.

Date: February 2022

Formats: txt xml json pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9192

The Network Service Header (NSH) specification defines two possible methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MDType 0x1 uses a fixed-length Context Header. The allocation of thisContext Header, i.e., its structure and semantics, has not been standardized. This memo defines the Timestamp Context Header, which is an NSH fixed-length Context Header that incorporates the packet's timestamp, a sequence number, and a source interface identifier.
Although the definition of the Context Header presented in this document has not been standardized by the IETF, it has been implemented in silicon by several manufacturers and is published here to facilitate interoperability.

RFC 9193 Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format

Authors: A. Keränen, C. Bormann.

Date: June 2022

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9193

The Sensor Measurement Lists (SenML) media types support multiple types of values, from numbers to text strings and arbitrary binaryData Values. In order to facilitate processing of binary DataValues, this document specifies a pair of new SenML fields for indicating the content format of those binary Data Values, i.e., their Internet media type, including parameters as well as any content codings applied.

RFC 9194 A YANG Module for IS-IS Reverse Metric

Authors: C. Hopps.

Date: October 2022

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9194

This document defines a YANG module for managing the reverse metric extension to the Intermediate System to Intermediate System (IS-IS) intra-domain routing information exchange protocol.

RFC 9195 A File Format for YANG Instance Data

Authors: B. Lengyel, B. Claise.

Date: February 2022

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9195

There is a need to document data defined in YANG models at design time, implementation time, or when a live server is unavailable.This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models and annotates it with metadata.

RFC 9196 YANG Modules Describing Capabilities for Systems and Datastore Update Notifications

Authors: B. Lengyel, A. Clemm, B. Claise.

Date: February 2022

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9196

This document defines two YANG modules, "ietf-system-capabilities" and "ietf-notification-capabilities".
The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG-related system capabilities for servers. The module can be used to report capability information from the server at runtime or at implementation time by making use of the YANG instance data file format.
The module "ietf-notification-capabilities" augments "ietf-system- capabilities" to specify capabilities related to "Subscription toYANG Notifications for Datastore Updates" (RFC 8641).

RFC 9197 Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)

Authors: F. Brockners, Ed., S. Bhandari, Ed., T. Mizrahi, Ed..

Date: May 2022

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9197

In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such asNetwork Service Header (NSH), Segment Routing, Generic NetworkVirtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets.

RFC 9198 Advanced Unidirectional Route Assessment (AURA)

Authors: J. Alvarez-Hamelin, A. Morton, J. Fabini, C. Pignataro, R. Geib.

Date: May 2022

Formats: txt html pdf json xml

Updates: RFC 2330

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9198

This memo introduces an advanced unidirectional route assessment(AURA) metric and associated measurement methodology based on the IPPerformance Metrics (IPPM) framework (RFC 2330). This memo updatesRFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multipath technologies.

RFC 9199 Considerations for Large Authoritative DNS Server Operators

Authors: G. Moura, W. Hardaker, J. Heidemann, M. Davids.

Date: March 2022

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9199

Recent research work has explored the deployment characteristics and configuration of the Domain Name System (DNS). This document summarizes the conclusions from these research efforts and offers specific, tangible considerations or advice to authoritative DNS server operators. Authoritative server operators may wish to follow these considerations to improve their DNS services.
It is possible that the results presented in this document could be applicable in a wider context than just the DNS protocol, as some of the results may generically apply to any stateless/short-duration anycasted service.
This document is not an IETF consensus document: it is published for informational purposes.

RFC 9200 Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)

Authors: L. Seitz, G. Selander, E. Wahlstroem, S. Erdtman, H. Tschofenig.

Date: August 2022

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9200

This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments calledACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases.

RFC 9201 Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)

Authors: L. Seitz.

Date: August 2022

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9201

This specification defines new parameters and encodings for the OAuth2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments(ACE). These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client.

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 9203 The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework

Authors: F. Palombini, L. Seitz, G. Selander, M. Gunnarsson.

Date: August 2022

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9203

This document specifies a profile for the Authentication andAuthorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments(OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.

RFC 9204 QPACK: Field Compression for HTTP/3

Authors: C. Krasic, M. Bishop, A. Frindell, Ed..

Date: June 2022

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9204

This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3.This is a variation of HPACK compression that seeks to reduce head- of-line blocking.

RFC 9205 Building Protocols with HTTP

Authors: M. Nottingham.

Date: June 2022

Formats: txt html pdf xml json

Obsoletes: RFC 3205

Also: BCP 0056

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9205

Applications often use HTTP as a substrate to create HTTP-based APIs.This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols usingHTTP for deployment on the Internet but might be applicable in other situations.This document obsoletes RFC 3205.

RFC 9206 Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec)

Authors: L. Corcoran, M. Jenkins.

Date: February 2022

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9206

The United States Government has published the National SecurityAgency's Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using theUnited States National Security Agency's CNSA Suite algorithms inInternet Protocol Security (IPsec). It applies to the capabilities, configuration, and operation of all components of US NationalSecurity Systems (described in NIST Special Publication 800-59) that employ IPsec. This document is also appropriate for all other USGovernment systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

RFC 9207 OAuth 2.0 Authorization Server Issuer Identification

Authors: K. Meyer zu Selhausen, D. Fett.

Date: March 2022

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9207

This document specifies a new parameter called iss. This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks".

RFC 9208 IMAP QUOTA Extension

Authors: A. Melnikov.

Date: March 2022

Formats: txt html xml pdf json

Obsoletes: RFC 2087

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9208

This document defines a QUOTA extension of the Internet MessageAccess Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol.
This document obsoletes RFC 2087 but attempts to remain backwards compatible whenever possible.

RFC 9209 The Proxy-Status HTTP Response Header Field

Authors: M. Nottingham, P. Sikora.

Date: June 2022

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9209

This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors.

RFC 9210 DNS Transport over TCP - Operational Requirements

Authors: J. Kristoff, D. Wessels.

Date: March 2022

Formats: txt html pdf xml json

Updates: RFC 1123, RFC 1536

Also: BCP 0235

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9210

This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried overTCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld.

RFC 9211 The Cache-Status HTTP Response Header Field

Authors: M. Nottingham.

Date: June 2022

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9211

To aid debugging, HTTP caches often append header fields to a response, explaining how they handled the request in an ad hoc manner. This specification defines a standard mechanism to do so that is aligned with HTTP's caching model.

RFC 9212 Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)

Authors: N. Gajcowski, M. Jenkins.

Date: March 2022

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9212

The United States Government has published the National SecurityAgency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using theUnited States National Security Agency's CNSA Suite algorithms with the Secure Shell Transport Layer Protocol and the Secure ShellAuthentication Protocol. It applies to the capabilities, configuration, and operation of all components of US NationalSecurity Systems (described in NIST Special Publication 800-59) that employ Secure Shell (SSH). This document is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

RFC 9213 Targeted HTTP Cache Control

Authors: S. Ludin, M. Nottingham, Y. Wu.

Date: June 2022

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9213

This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches. It also defines one such header field, theCDN-Cache-Control response header field, which is targeted at content delivery network (CDN) caches.

RFC 9214 OSPFv3 Code Point for MPLS LSP Ping

Authors: N. Nainar, C. Pignataro, M. Aissaoui.

Date: April 2022

Formats: txt html xml pdf json

Updates: RFC 8287

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9214

IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registries under the "Multiprotocol Label Switching (MPLS) Label Switched Paths(LSPs) Ping Parameters" registry. RFC 8287 defines the code points for Open Shortest Path First (OSPF) and Intermediate System toIntermediate System (IS-IS) protocols.
This document specifies the code point to be used in the Segment ID sub-TLV and Downstream Detailed Mapping (DDMAP) TLV when the InteriorGateway Protocol (IGP) is OSPFv3. This document also updatesRFC 8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2 and by defining the behavior when theSegment ID sub-TLV indicates the use of IPv6.

RFC 9215 Using GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with the Internet X.509 Public Key Infrastructure

Authors: D. Baryshkov, Ed., V. Nikolaev, A. Chelpanov.

Date: March 2022

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9215

This document describes encoding formats, identifiers, and parameter formats for the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for use in the Internet X.509 Public Key Infrastructure (PKI).
This specification is developed to facilitate implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used in this document.

RFC 9216 S/MIME Example Keys and Certificates

Authors: D. K. Gillmor, Ed..

Date: April 2022

Formats: txt json html pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9216

The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples.

RFC 9217 Current Open Questions in Path-Aware Networking

Authors: B. Trammell.

Date: March 2022

Formats: txt json pdf html xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9217

In contrast to the present Internet architecture, a path-aware internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and it provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet- connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet.
This document poses questions in path-aware networking, open as of2021, that must be answered in the design, development, and deployment of path-aware internetworks. It was originally written to frame discussions in the Path Aware Networking Research Group(PANRG), and has been published to snapshot current thinking in this space.

RFC 9218 Extensible Prioritization Scheme for HTTP

Authors: K. Oku, L. Pardue.

Date: June 2022

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9218

This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility.

RFC 9219 S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)

Authors: A. Melnikov.

Date: April 2022

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9219

This document specifies an extension to "The JSON Meta ApplicationProtocol (JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verification status.

RFC 9220 Bootstrapping WebSockets with HTTP/3

Authors: R. Hamilton.

Date: June 2022

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9220

The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but theHTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3.

RFC 9221 An Unreliable Datagram Extension to QUIC

Authors: T. Pauly, E. Kinnear, D. Schinazi.

Date: March 2022

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9221

This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over aQUIC connection.

RFC 9222 Guidelines for Autonomic Service Agents

Authors: B. E. Carpenter, L. Ciavaglia, S. Jiang, P. Peloso.

Date: March 2022

Formats: txt json pdf html xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9222

This document proposes guidelines for the design of Autonomic ServiceAgents for autonomic networks. Autonomic Service Agents, together with the Autonomic Network Infrastructure, the Autonomic ControlPlane, and the GeneRic Autonomic Signaling Protocol, constitute base elements of an autonomic networking ecosystem.

RFC 9223 Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE)

Authors: W. Zia, T. Stockhammer, L. Chaponniere, G. Mandyam, M. Luby.

Date: April 2022

Formats: txt json pdf html xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9223

The Real-time Transport Object delivery over Unidirectional Transport(ROUTE) protocol is specified for robust delivery of ApplicationObjects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport.Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers; for example, it can be a file, a Dynamic Adaptive Streaming over HTTP(DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, etc.The ROUTE protocol also supports low-latency streaming applications.
The ROUTE protocol is suitable for unicast, broadcast, and multicast transport. Therefore, it can be run over UDP/IP, including multicastIP. The ROUTE protocol can leverage the features of the underlying protocol layer, e.g., to provide security, it can leverage IP security protocols such as IPsec.
This document specifies the ROUTE protocol such that it could be used by a variety of services for delivery of Application Objects by specifying their own profiles of this protocol (e.g., by adding or constraining some features).
This is not an IETF specification and does not have IETF consensus.

RFC 9224 Finding the Authoritative Registration Data Access Protocol (RDAP) Service

Authors: M. Blanchet.

Date: March 2022

Formats: txt html json pdf xml

Obsoletes: RFC 7484

Also: STD 0095

Status: INTERNET STANDARD

DOI: 10.17487/RFC 9224

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. This document obsoletes RFC 7484.

RFC 9225 Software Defects Considered Harmful

Authors: J. Snijders, C. Morrow, R. van Mook.

Date: 1 April 2022

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9225

This document discourages the practice of introducing software defects in general and in network protocol implementations specifically. Software defects are one of the largest cost drivers for the networking industry. This document is intended to clarify the best current practice in this regard.

RFC 9226 Bioctal: Hexadecimal 2.0

Authors: M. Breen.

Date: 1 April 2022

Formats: txt xml pdf json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9226

The prevailing hexadecimal system was chosen for congruence with groups of four binary digits, but its design exhibits an indifference to cognitive factors. An alternative is introduced that is designed to reduce brain cycles in cases where a hexadecimal number should be readily convertible to binary by a human being.

RFC 9227 Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols

Authors: V. Smyslov.

Date: March 2022

Formats: txt xml json pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9227

This document defines a set of encryption transforms for use in theEncapsulating Security Payload (ESP) and in the Internet Key Exchange version 2 (IKEv2) protocols, which are parts of the IP Security(IPsec) protocol suite. The transforms are based on the GOST R34.12-2015 block ciphers (which are named "Magma" and "Kuznyechik") in Multilinear Galois Mode (MGM) and the external rekeying approach.
This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used in this document.

RFC 9228 Delivered-To Email Header Field

Authors: D. Crocker, Ed..

Date: April 2022

Formats: txt xml html pdf json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9228

The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as throughSMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, a receiving system's delivery process can produce local address transformations.
It can be helpful for a message to have a common way to record each delivery in such a sequence, noting each address used in the sequence to that recipient, such as for (1) analyzing the path a message has taken, (2) loop detection, or (3) formulating the author's address in a reply message. This document defines a header field for this information.
Email handling information discloses details about the email infrastructure, as well as about a particular recipient; this can raise privacy concerns.
A header field such as this is not automatically assured of widespread use. Therefore, this document is being published as anExperimental RFC, looking for constituency and for operational utility. This document was produced through the IndependentSubmission Stream and was not subject to the IETF's approval process.

RFC 9229 IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol

Authors: J. Chroboczek.

Date: May 2022

Formats: txt xml pdf html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9229

This document defines an extension to the Babel routing protocol that allows announcing routes to an IPv4 prefix with an IPv6 next hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address.

RFC 9230 Oblivious DNS over HTTPS

Authors: E. Kinnear, P. McManus, T. Pauly, T. Verma, C.A. Wood.

Date: June 2022

Formats: txt pdf html xml json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9230

This document describes a protocol that allows clients to hide theirIP addresses from DNS resolvers via proxying encrypted DNS over HTTPS(DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.
This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation.

RFC 9231 Additional XML Security Uniform Resource Identifiers (URIs)

Authors: D. Eastlake 3rd.

Date: July 2022

Formats: txt pdf html xml json

Obsoletes: RFC 6931

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9231

This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. TheseURIs identify algorithms and types of information. This document also obsoletes and corrects three errata against RFC 6931.

RFC 9232 Network Telemetry Framework

Authors: H. Song, F. Qin, P. Martinez-Julia, L. Ciavaglia, A. Wang.

Date: May 2022

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9232

Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments.

RFC 9233 Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 12.0.0

Authors: P. Fältström.

Date: March 2022

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9233

This document describes the changes between Unicode 6.0.0 and Unicode12.0.0 in the context of the current version of InternationalizedDomain Names for Applications 2008 (IDNA2008). Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. IDNA2008 allows adding exceptions to the algorithm for backward compatibility; however, this document does not add any such exceptions. This document provides the necessary tables to IANA to make its database consistent withUnicode 12.0.0.
To improve understanding, this document describes systems that are being used as alternatives to those that conform to IDNA2008.

RFC 9234 Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages

Authors: A. Azimov, E. Bogomazov, R. Bush, K. Patel, K. Sriram.

Date: May 2022

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9234

Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider.These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes).Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.

RFC 9235 TCP Authentication Option (TCP-AO) Test Vectors

Authors: J. Touch, J. Kuusisaari.

Date: May 2022

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9235

This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCPAuthentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: KDF_HMAC_SHA1 and HMAC-SHA-1-96, and KDF_AES_128_CMAC and AES-128-CMAC-96. The vectors also validate both whole TCP segments as well as segments whose options are excluded for middlebox traversal.

RFC 9236 Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service

Authors: J. Hong, T. You, V. Kafle.

Date: April 2022

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9236

This document describes architectural considerations and implications related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN). It explains how the ICN architecture can change when an NRS is utilized and how its use influences the ICN routing system. This document is a product of the Information-Centric Networking Research Group (ICNRG).

RFC 9237 An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE)

Authors: C. Bormann.

Date: August 2022

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9237

Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as theInternet of Things.
This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use withRepresentational State Transfer (REST) resources identified by URI path.

RFC 9238 Loading Manufacturer Usage Description (MUD) URLs from QR Codes

Authors: M. Richardson, J. Latour, H. Habibi Gharakheili.

Date: May 2022

Formats: txt pdf xml html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9238

This informational document details a protocol to load ManufacturerUsage Description (MUD) definitions from RFC 8520 for devices that do not have them integrated.
This document is published to inform the Internet community of this mechanism to allow interoperability and to serve as a basis of other standards work if there is interest.

RFC 9239 Updates to ECMAScript Media Types

Authors: M. Miller, M. Borins, M. Bynens, B. Farias.

Date: May 2022

Formats: txt html pdf xml json

Obsoletes: RFC 4329

Status: INFORMATIONAL

DOI: 10.17487/RFC 9239

This document describes the registration of media types for theECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC 4329 ("Scripting Media Types)", replacing the previous registrations with information and requirements aligned with common usage and implementation experiences.

RFC 9240 An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps

Authors: W. Roome, S. Randriamasy, Y. Yang, J. Zhang, K. Gao.

Date: July 2022

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9240

This document specifies an extension to the base Application-LayerTraffic Optimization (ALTO) Protocol that generalizes the concept of"endpoint properties", which have been tied to IP addresses so far, to entities defined by a wide set of objects. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO Protocol. While supporting the endpoints and related Endpoint Property Service defined in RFC 7285, the ALTOProtocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties for specific endpoints to entire entity property maps. These extensions introduce additional features that allow entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types.

RFC 9241 Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO)

Authors: J. Seedorf, Y. Yang, K. Ma, J. Peterson, J. Zhang.

Date: July 2022

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9241

The Content Delivery Networks Interconnection (CDNI) framework in RFC6707 defines a set of protocols to interconnect CDNs to achieve multiple goals, including extending the reach of a given CDN. A CDNIRequest Routing Footprint & Capabilities Advertisement interface(FCI) is needed to achieve the goals of a CDNI. RFC 8008 defines theFCI semantics and provides guidelines on the FCI protocol, but the exact protocol is not specified. This document defines a newApplication-Layer Traffic Optimization (ALTO) service, called "CDNIAdvertisement Service", that provides an implementation of the FCI, following the guidelines defined in RFC 8008.

RFC 9242 Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: V. Smyslov.

Date: May 2022

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9242

This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant toQuantum Computers (QCs) for IKE SA establishment. The IntermediateExchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established.

RFC 9243 A YANG Data Model for DHCPv6 Configuration

Authors: I. Farrer, Ed..

Date: June 2022

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9243

This document describes YANG data models for the configuration and management of Dynamic Host Configuration Protocol for IPv6 (DHCPv6)(RFC 8415) servers, relays, and clients.

RFC 9244 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry

Authors: M. Boucadair, Ed., T. Reddy.K, Ed., E. Doron, M. Chen, J. Shallow.

Date: June 2022

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9244

This document aims to enrich the Distributed Denial-of-Service OpenThreat Signaling (DOTS) signal channel protocol with various telemetry attributes, allowing for optimal Distributed Denial-of-Service (DDoS) attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator in choosing the DDoS mitigation techniques and performing optimal DDoS attack mitigation.
This document specifies two YANG modules: one for representing DOTS telemetry message types and one for sharing the attack mapping details over the DOTS data channel.

RFC 9245 IETF Discussion List Charter

Authors: L. Eggert, S. Harris.

Date: June 2022

Formats: txt json pdf xml html

Obsoletes: RFC 3005

Updates: RFC 3683

Also: BCP 0045

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9245

The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope.
This document obsoletes RFC 3005 and updates RFC 3683.

RFC 9246 URI Signing for Content Delivery Network Interconnection (CDNI)

Authors: R. van Brandenburg, K. Leung, P. Sorber.

Date: June 2022

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9246

This document describes how the concept of URI Signing supports the content access control requirements of Content Delivery NetworkInterconnection (CDNI) and proposes a URI Signing method as a JSONWeb Token (JWT) profile.
The proposed URI Signing method specifies the information needed to be included in the URI to transmit the signed JWT, as well as the claims needed by the signed JWT to authorize a User Agent (UA). The mechanism described can be used both in CDNI and single ContentDelivery Network (CDN) scenarios.

RFC 9247 BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD)

Authors: Z. Li, S. Zhuang, K. Talaulikar, Ed., S. Aldrin, J. Tantsura, G. Mirsky.

Date: June 2022

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9247

Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The link-state routing protocols (IS-IS and OSPF) have been extended to advertise the S-BFD Discriminators.
This document defines extensions to the BGP - Link State (BGP-LS) address family to carry the S-BFD Discriminators' information viaBGP.

RFC 9248 Interoperability Profile for Relay User Equipment

Authors: B. Rosen.

Date: June 2022

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9248

Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or has a speech disability using an interpreter (i.e., a Communications Assistant(CA)) connected via a videophone to the sign language speaker and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link.Often the interpreters may be employed by a company or agency, termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service and subsequently to CAs and other sign language speakers. It is desirable that the videophones used by the sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between sign language speakers work. This document describes the interface between a videophone and a provider.

RFC 9249 A YANG Data Model for NTP

Authors: N. Wu, D. Dhody, Ed., A. Sinha, Ed., A. Kumar S N, Y. Zhao.

Date: July 2022

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9249

This document defines a YANG data model that can be used to configure and manage Network Time Protocol (NTP) version 4. It can also be used to configure and manage version 3. The data model includes configuration data and state data.

RFC 9250 DNS over Dedicated QUIC Connections

Authors: C. Huitema, S. Dickinson, A. Mankin.

Date: May 2022

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9250

This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC7858, and latency characteristics similar to classic DNS over UDP.This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.

RFC 9251 Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)

Authors: A. Sajassi, S. Thoria, M. Mishra, K. Patel, J. Drake, W. Lin.

Date: June 2022

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9251

This document describes how to support endpoints running the InternetGroup Management Protocol (IGMP) or Multicast Listener Discovery(MLD) efficiently for the multicast services over an Ethernet VPN(EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPNProvider Edges (PEs).

RFC 9252 BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)

Authors: G. Dawra, Ed., K. Talaulikar, Ed., R. Raszuk, B. Decraene, S. Zhuang, J. Rabadan.

Date: July 2022

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9252

This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), EthernetVPN (EVPN), and Internet services. It builds on "BGP/MPLS IP VirtualPrivate Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN"(RFC 7432).

RFC 9253 Support for iCalendar Relationships

Authors: M. Douglass.

Date: August 2022

Formats: txt html xml pdf json

Updates: RFC 5545

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9253

This specification updates the iCalendar RELATED-TO property defined in RFC 5545 by adding new relation types and introduces new iCalendar properties (LINK, CONCEPT, and REFID) to allow better linking and grouping of iCalendar components and related data.

RFC 9254 Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)

Authors: M. Veillette, Ed., I. Petrov, Ed., A. Pelov, C. Bormann, M. Richardson.

Date: July 2022

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9254

YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of RemoteProcedure Call (RPC) operations or actions, and notifications.
This document defines encoding rules for YANG in the Concise BinaryObject Representation (CBOR) (RFC 8949).

RFC 9255 The 'I' in RPKI Does Not Stand for Identity

Authors: R. Bush, R. Housley.

Date: June 2022

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9255

There is a false notion that Internet Number Resources (INRs) in theRPKI can be associated with the real-world identity of the 'holder' of an INR. This document specifies that RPKI does not associate to the INR holder.

RFC 9256 Segment Routing Policy Architecture

Authors: C. Filsfils, K. Talaulikar, Ed., D. Voyer, A. Bogdanov, P. Mattes.

Date: July 2022

Formats: txt html json pdf xml

Updates: RFC 8402

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9256

Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.
This document updates RFC 8402 as it details the concepts of SRPolicy and steering into an SR Policy.

RFC 9257 Guidance for External Pre-Shared Key (PSK) Usage in TLS

Authors: R. Housley, J. Hoyland, M. Sethi, C. A. Wood.

Date: July 2022

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9257

This document provides usage guidance for external Pre-Shared Keys(PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when externalPSKs are used.

RFC 9258 Importing External Pre-Shared Keys (PSKs) for TLS 1.3

Authors: D. Benjamin, C. A. Wood.

Date: July 2022

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9258

This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3.

RFC 9259 Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)

Authors: Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M. Chen.

Date: June 2022

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9259

This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) network.The document also specifies the OAM flag (O-flag) in the SegmentRouting Header (SRH) for performing controllable and predictable flow sampling from segment endpoints. In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain.

RFC 9260 Stream Control Transmission Protocol

Authors: R. Stewart, M. Tüxen, K. Nielsen.

Date: June 2022

Formats: txt xml json pdf html

Obsoletes: RFC 4460, RFC 4960, RFC 6096, RFC 7053, RFC 8540

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9260

This document describes the Stream Control Transmission Protocol(SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.
SCTP was originally designed to transport Public Switched TelephoneNetwork (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC.
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 MaximumTransmission Unit (PMTU) 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 9261 Exported Authenticators in TLS

Authors: N. Sullivan.

Date: July 2022

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9261

This document describes a mechanism that builds on Transport LayerSecurity (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer.

RFC 9262 Tree Engineering for Bit Index Explicit Replication (BIER-TE)

Authors: T. Eckert, Ed., M. Menth, G. Cauchie.

Date: October 2022

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9262

This memo describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index ExplicitReplication" (BIER) packets (RFC 8279); it is called "TreeEngineering for Bit Index Explicit Replication" (BIER-TE) and is intended to be used as the path steering mechanism for TrafficEngineering with BIER.
BIER-TE introduces a new semantic for "bit positions" (BPs). TheseBPs indicate adjacencies of the network topology, as opposed to (non-TE) BIER in which BPs indicate "Bit-Forwarding Egress Routers"(BFERs). A BIER-TE "packets BitString" therefore indicates the edges of the (loop-free) tree across which the packets are forwarded byBIER-TE. BIER-TE can leverage BIER forwarding engines with little changes. Co-existence of BIER and BIER-TE forwarding in the same domain is possible -- for example, by using separate BIER"subdomains" (SDs). Except for the optional routed adjacencies,BIER-TE does not require a BIER routing underlay and can therefore operate without depending on a routing protocol such as the "InteriorGateway Protocol" (IGP).

RFC 9263 Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers

Authors: Y. Wei, Ed., U. Elzur, S. Majee, C. Pignataro, D. Eastlake 3rd.

Date: August 2022

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9263

Service Function Chaining (SFC) uses the Network Service Header (NSH)(RFC 8300) to steer and provide context metadata (MD) with each packet. Such metadata can be of various types, including MD Type 2, consisting of Variable-Length Context Headers. This document specifies several such Context Headers that can be used within aService Function Path (SFP).

RFC 9264 Linkset: Media Types and a Link Relation Type for Link Sets

Authors: E. Wilde, H. Van de Sompel.

Date: July 2022

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9264

This specification defines two formats and associated media types for representing sets of links as standalone documents. One format is based on JSON, and the other is aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support the discovery of sets of links.

RFC 9265 Forward Erasure Correction (FEC) Coding and Congestion Control in Transport

Authors: N. Kuhn, E. Lochin, F. Michel, M. Welzl.

Date: July 2022

Formats: txt json pdf html xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9265

Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems.
This document is the product of the Coding for Efficient NetworkCommunications Research Group (NWCRG). The scope of the document is end-to-end communications; FEC coding for tunnels is out of the scope of the document.

RFC 9266 Channel Bindings for TLS 1.3

Authors: S. Whited.

Date: July 2022

Formats: txt html xml pdf json

Updates: RFC 5801, RFC 5802, RFC 5929, RFC 7677

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9266

This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use ofChannel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and7677.

RFC 9267 Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing

Authors: S. Dashevskyi, D. dos Santos, J. Wetzels, A. Amri.

Date: July 2022

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9267

This memo describes common vulnerabilities related to Domain NameSystem (DNS) resource record (RR) processing as seen in several DNS client implementations. These vulnerabilities may lead to successfulDenial-of-Service and Remote Code Execution attacks against the affected software. Where applicable, violations of RFC 1035 are mentioned.

RFC 9268 IPv6 Minimum Path MTU Hop-by-Hop Option

Authors: R. Hinden, G. Fairhurst.

Date: August 2022

Formats: txt json xml pdf html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9268

This document specifies a new IPv6 Hop-by-Hop Option that is used to record the Minimum Path MTU (PMTU) along the forward path between a source host to a destination host. The recorded value can then be communicated back to the source using the return Path MTU field in the Option.

RFC 9269 Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks

Authors: P. Suthar, M. Stolic, A. Jangam, Ed., D. Trossen, R. Ravindran.

Date: August 2022

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9269

A 4G mobile network uses IP-based transport for the control plane to establish the data session at the user plane for the actual data delivery. In the existing architecture, IP-based unicast is used for the delivery of multimedia content to a mobile terminal, where each user is receiving a separate stream from the server. From a bandwidth and routing perspective, this approach is inefficient.Evolved multimedia broadcast and multicast service (eMBMS) provides capabilities for delivering contents to multiple users simultaneously, but its deployment is very limited or at an experimental stage due to numerous challenges. The focus of this document is to list the options for using Information-CentricNetworking (ICN) in 4G mobile networks and elaborate the experimental setups for its further evaluation. The experimental setups discussed provide guidance for using ICN either natively or with an existing mobility protocol stack. With further investigations based on the listed experiments, ICN with its inherent capabilities such as network-layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge may provide a viable alternative to IP transport in 4G mobile networks.

RFC 9270 GMPLS Signaling Extensions for Shared Mesh Protection

Authors: J. He, I. Busi, J. Ryoo, B. Yoon, P. Park.

Date: August 2022

Formats: txt json pdf xml html

Updates: RFC 4872, RFC 4873

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9270

ITU-T Recommendation G.808.3 defines the generic aspects of a SharedMesh Protection (SMP) mechanism, where the difference between SMP andShared Mesh Restoration (SMR) is also identified. ITU-TRecommendation G.873.3 defines the protection switching operation and associated protocol for SMP at the Optical Data Unit (ODU) layer.RFC 7412 provides requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - TransportProfile (MPLS-TP) network.
This document updates RFCs 4872 and 4873 to provide extensions forGeneralized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the SMP mechanism.

RFC 9271 Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses

Authors: R. Price, Ed..

Date: August 2022

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9271

This document describes the command/response protocol currently used in the management of Uninterruptible Power Supply (UPS) units and other power devices often deployed in small offices and in IT installations subject to an erratic public power supply. The UPS units typically interface to an Attachment Daemon in the system they protect. This daemon is in turn polled by a Management Daemon that notifies users and system administrators of power supply incidents and automates system shutdown decisions. The commands and responses described by this document are exchanged between the UPS AttachmentDaemon and the Management Daemon. The practice current when this protocol was first developed risks weak security, and this is addressed in the Security Considerations sections of this document.

RFC 9272 Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER)

Authors: Z. Zhang, T. Przygienda, A. Dolganow, H. Bidgoli, IJ. Wijnands, A. Gulko.

Date: September 2022

Formats: txt html json xml pdf

Updates: RFC 8401, RFC 8444

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9272

This document specifies general rules for the interaction between theBIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay path calculation within the Bit Index Explicit Replication (BIER) architecture. The semantics defined in this document update RFC 8401 and RFC 8444. This document also updates the "BIER Algorithm" registry established in RFC 8401.

RFC 9273 Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges

Authors: K. Matsuzono, H. Asaeda, C. Westphal.

Date: August 2022

Formats: txt html xml json pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9273

This document describes the current research outcomes in NetworkCoding (NC) for Content-Centric Networking (CCNx) / Named DataNetworking (NDN) and clarifies the technical considerations and potential challenges for applying NC in CCNx/NDN. This document is the product of the Coding for Efficient Network CommunicationsResearch Group (NWCRG) and the Information-Centric NetworkingResearch Group (ICNRG).

RFC 9274 A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol

Authors: M. Boucadair, Q. Wu.

Date: July 2022

Formats: txt json xml pdf html

Updates: RFC 7285

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9274

This document creates a new IANA registry for tracking cost modes supported by the Application-Layer Traffic Optimization (ALTO)Protocol. Also, this document relaxes a constraint that was imposed by the ALTO specification on allowed cost mode values.
This document updates RFC 7285.

RFC 9275 An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector

Authors: K. Gao, Y. Lee, S. Randriamasy, Y. Yang, J. Zhang.

Date: September 2022

Formats: txt json html xml pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9275

This document is an extension to the base Application-Layer TrafficOptimization (ALTO) protocol. It extends the ALTO cost map and ALTO property map services so that an application can decide to which endpoint(s) to connect based not only on numerical/ordinal cost values but also on fine-grained abstract information regarding the paths. This is useful for applications whose performance is impacted by specific components of a network on the end-to-end paths, e.g., they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This extension introduces a new abstraction called the "Abstract Network Element"(ANE) to represent these components and encodes a network path as a vector of ANEs. Thus, it provides a more complete but still abstract graph representation of the underlying network(s) for informed traffic optimization among endpoints.

RFC 9276 Guidance for NSEC3 Parameter Settings

Authors: W. Hardaker, V. Dukhovni.

Date: August 2022

Formats: txt pdf html xml json

Updates: RFC 5155

Also: BCP 0236

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9276

NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that there are no names that exist between two domain names within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience. This document updates RFC 5155 with guidance about selecting NSEC3 iteration and salt parameters.

RFC 9277 On Stable Storage for Items in Concise Binary Object Representation (CBOR)

Authors: M. Richardson, C. Bormann.

Date: August 2022

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9277

This document defines a stored ("file") format for Concise BinaryObject Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command.

RFC 9278 JWK Thumbprint URI

Authors: M. Jones, K. Yasuda.

Date: August 2022

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9278

This specification registers a kind of URI that represents a JSON WebKey (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638.This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs.

RFC 9279 Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension

Authors: M. Sivakumar, S. Venaas, Z. Zhang, H. Asaeda.

Date: August 2022

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9279

This document specifies a generic mechanism to extend IGMPv3 andMulticast Listener Discovery Version 2 (MLDv2) by using a list ofTLVs (Type, Length, and Value).

RFC 9280 RFC Editor Model (Version 3)

Authors: P. Saint-Andre, Ed..

Date: June 2022

Formats: txt json html pdf xml

Obsoletes: RFC 8728

Updates: RFC 7841, RFC 8729, RFC 8730

Status: INFORMATIONAL

DOI: 10.17487/RFC 9280

This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC SeriesWorking Group (RSWG), which produces policy proposals, and the RFCSeries Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFCProduction Center (RPC) as contractually overseen by the IETFAdministration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series ConsultingEditor (RSCE), and IETF LLC. Finally, this document establishes theEditorial Stream for publication of future policy definition documents produced through the processes defined herein.
This document obsoletes RFC 8728. This document updates RFCs 7841,8729, and 8730.

RFC 9281 Entities Involved in the IETF Standards Process

Authors: R. Salz.

Date: June 2022

Formats: txt json pdf xml html

Obsoletes: RFC 2028

Also: BCP 0011

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9281

This document describes the individuals and organizations involved in the IETF standards process, as described in BCP 9. It includes brief descriptions of the entities involved and the role they play in the standards process.
The IETF and its structure have undergone many changes since RFC 2028 was published in 1996. This document reflects the changed organizational structure of the IETF and obsoletes RFC 2028.

RFC 9282 Responsibility Change for the RFC Series

Authors: B. Rosen.

Date: June 2022

Formats: txt xml html pdf json

Updates: RFC 2026

Also: BCP 0009

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9282

In RFC 9280, responsibility for the RFC Series moved to the RFCSeries Working Group and the RFC Series Approval Board. It is no longer the responsibility of the RFC Editor, and the role of the IAB in the RFC Series is altered. Accordingly, in Section 2.1 of RFC2026, the sentence "RFC publication is the direct responsibility of the RFC Editor, under the general direction of the IAB" is deleted.

RFC 9283 IAB Charter Update for RFC Editor Model

Authors: B. Carpenter, Ed..

Date: June 2022

Formats: txt xml html pdf json

Updates: RFC 2850

Also: BCP 0039

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9283

This document updates the IAB Charter (RFC 2850) to be consistent with version 3 of the RFC Editor Model (RFC 9280).

RFC 9284 Multihoming Deployment Considerations for DDoS Open Threat Signaling (DOTS)

Authors: M. Boucadair, T. Reddy.K, W. Pan.

Date: August 2022

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9284

This document discusses multihoming considerations for DDoS OpenThreat Signaling (DOTS). The goal is to provide some guidance forDOTS clients and client-domain DOTS gateways when multihomed.

RFC 9285 The Base45 Data Encoding

Authors: P. Fältström, F. Ljunggren, D.W. van Gulik.

Date: August 2022

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9285

This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes.

RFC 9286 Manifests for the Resource Public Key Infrastructure (RPKI)

Authors: R. Austein, G. Huston, S. Kent, M. Lepinski.

Date: June 2022

Formats: txt html pdf xml json

Obsoletes: RFC 6486

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9286

This document defines a "manifest" for use in the Resource Public KeyInfrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate,Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486.

RFC 9287 Greasing the QUIC Bit

Authors: M. Thomson.

Date: August 2022

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9287

This document describes a method for negotiating the ability to send an arbitrary value for the second-most significant bit in QUIC packets.

RFC 9288 Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers

Authors: F. Gont, W. Liu.

Date: August 2022

Formats: txt json pdf html xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9288

This document analyzes the security implications of IPv6 ExtensionHeaders and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain.Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary.

RFC 9289 Towards Remote Procedure Call Encryption by Default

Authors: T. Myklebust, C. Lever, Ed..

Date: September 2022

Formats: txt json pdf xml html

Updates: RFC 5531

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9289

This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption ofRemote Procedure Call (RPC) transactions while they are in transit.The proposed mechanism interoperates with Open Network Computing(ONC) RPC implementations that do not support it. This document updates RFC 5531.

RFC 9290 Concise Problem Details for Constrained Application Protocol (CoAP) APIs

Authors: T. Fossati, C. Bormann.

Date: October 2022

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9290

This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational StateTransfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807.

RFC 9291 A YANG Network Data Model for Layer 2 VPNs

Authors: M. Boucadair, Ed., O. Gonzalez de Dios, Ed., S. Barguil, L. Munoz.

Date: September 2022

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9291

This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). TheL2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.
Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types.

RFC 9292 Binary Representation of HTTP Messages

Authors: M. Thomson, C. A. Wood.

Date: August 2022

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9292

This document defines a binary format for representing HTTP messages.

RFC 9293 Transmission Control Protocol (TCP)

Authors: W. Eddy, Ed..

Date: August 2022

Formats: txt html pdf xml json

Obsoletes: RFC 0793, RFC 0879, RFC 2873, RFC 6093, RFC 6429, RFC 6528, RFC 6691

Updates: RFC 1011, RFC 1122, RFC 5961

Also: STD 0007

Status: INTERNET STANDARD

DOI: 10.17487/RFC 9293

This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793.This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits fromRFC 793 have also been updated based on RFC 3168.

RFC 9294 Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS)

Authors: K. Talaulikar, Ed., P. Psenak, J. Tantsura.

Date: August 2022

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9294

Extensions have been defined for link-state routing protocols that enable distribution of application-specific link attributes for existing as well as newer applications such as Segment Routing (SR).This document defines extensions to the Border Gateway Protocol -Link State (BGP-LS) to enable the advertisement of these application- specific attributes as a part of the topology information from the network.

RFC 9295 Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers

Authors: S. Turner, S. Josefsson, D. McCarney, T. Ito.

Date: September 2022

Formats: txt pdf xml json html

Updates: RFC 8410

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9295

This document updates RFC 8410 to clarify existing semantics, and specify missing semantics, for key usage bits when used in certificates that support the Ed25519, Ed448, X25519, and X448Elliptic Curve Cryptography algorithms.

RFC 9296 ifStackTable for the Point-to-Point (P2P) Interface over a LAN Type: Definition and Examples

Authors: D. Liu, J. Halpern, C. Zhang.

Date: August 2022

Formats: txt html json xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9296

RFC 5309 defines the Point-to-Point (P2P) circuit type, one of the two circuit types used in the link-state routing protocols, and highlights that it is important to identify the correct circuit type when forming adjacencies, flooding link-state database packets, and monitoring the link state.
This document provides advice about the ifStack for the P2P interface over a LAN Type to facilitate operational control, maintenance, and statistics.

RFC 9297 HTTP Datagrams and the Capsule Protocol

Authors: D. Schinazi, L. Pardue.

Date: August 2022

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9297

This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection.
In HTTP/3, HTTP Datagrams can be sent unreliably using the QUICDATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections.
HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications.

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 9299 An Architectural Introduction to the Locator/ID Separation Protocol (LISP)

Authors: A. Cabellos, D. Saucez, Ed..

Date: October 2022

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9299

This document describes the architecture of the Locator/ID SeparationProtocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes; more details can be found in the protocol specifications,RFCs 9300 and 9301.

RFC 9300 The Locator/ID Separation Protocol (LISP)

Authors: D. Farinacci, V. Fuller, D. Meyer, D. Lewis, A. Cabellos, Ed..

Date: October 2022

Formats: txt json pdf xml html

Obsoletes: RFC 6830

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9300

This document describes the data plane protocol for the Locator/IDSeparation Protocol (LISP). LISP defines two namespaces: EndpointIdentifiers (EIDs), which identify end hosts; and Routing Locators(RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.
LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features.
This document obsoletes RFC 6830.

RFC 9301 Locator/ID Separation Protocol (LISP) Control Plane

Authors: D. Farinacci, F. Maino, V. Fuller, A. Cabellos, Ed..

Date: October 2022

Formats: txt json html pdf xml

Obsoletes: RFC 6830, RFC 6833

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9301

This document describes the control plane and Mapping Service for theLocator/ID Separation Protocol (LISP), implemented by two types ofLISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs(EIDs) to Routing Locator mapping databases.
By using this control plane service interface and communicating withMap-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) andEgress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced.
This document obsoletes RFCs 6830 and 6833.

RFC 9302 Locator/ID Separation Protocol (LISP) Map-Versioning

Authors: L. Iannone, D. Saucez, O. Bonaventure.

Date: October 2022

Formats: txt html xml pdf json

Obsoletes: RFC 6834

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9302

This document describes the Locator/ID Separation Protocol (LISP)Map-Versioning mechanism, which provides in-packet information aboutEndpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. This approach is based on associating a version number to EID-to-RLOC mappings and transporting such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers(ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism.
This document obsoletes RFC 6834, which is the initial experimental specifications of the mechanisms updated by this document.

RFC 9303 Locator/ID Separation Protocol Security (LISP-SEC)

Authors: F. Maino, V. Ermagan, A. Cabellos, D. Saucez.

Date: October 2022

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9303

This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP'sEndpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages.

RFC 9304 Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations

Authors: M. Boucadair, C. Jacquenet.

Date: October 2022

Formats: txt xml json pdf html

Obsoletes: RFC 8113

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9304

This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP Packet Type codepoint for each extension.
This document obsoletes RFC 8113.

RFC 9305 Locator/ID Separation Protocol (LISP) Generic Protocol Extension

Authors: F. Maino, Ed., J. Lemon, P. Agarwal, D. Lewis, M. Smith.

Date: October 2022

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9305

This document describes extensions to the Locator/ID SeparationProtocol (LISP) data plane, via changes to the LISP header, to support multiprotocol encapsulation and allow the introduction of new protocol capabilities.

RFC 9306 Vendor-Specific LISP Canonical Address Format (LCAF)

Authors: A. Rodriguez-Natal, V. Ermagan, A. Smirnov, V. Ashtaputre, D. Farinacci.

Date: October 2022

Formats: txt html pdf xml json

Updates: RFC 8060

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9306

This document describes a new Locator/ID Separation Protocol (LISP)Canonical Address Format (LCAF), the Vendor-Specific LCAF. This LCAF enables organizations to have implementation-specific encodings forLCAF addresses. This document updates RFC 8060.

RFC 9307 Report from the IAB Workshop on Analyzing IETF Data (AID) 2021

Authors: N. ten Oever, C. Cath, M. Kühlewind, C. S. Perkins.

Date: September 2022

Formats: txt html json pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9307

The "Show me the numbers: Workshop on Analyzing IETF Data (AID)" workshop was convened by the Internet Architecture Board (IAB) fromNovember 29 to December 2, 2021 and hosted by the IN-SIGHT.it project at the University of Amsterdam; however, it was converted to an online-only event. The workshop was organized into two discussion parts with a hackathon activity in between. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 9308 Applicability of the QUIC Transport Protocol

Authors: M. Kühlewind, B. Trammell.

Date: September 2022

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9308

This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols.

RFC 9309 Robots Exclusion Protocol

Authors: M. Koster, G. Illyes, H. Zeller, L. Sassman.

Date: September 2022

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9309

This document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control how content served by their services may be accessed, if at all, by automatic clients known as crawlers.Specifically, it adds definition language for the protocol, instructions for handling errors, and instructions for caching.

RFC 9310 X.509 Certificate Extension for 5G Network Function Types

Authors: R. Housley, S. Turner, J. Preuß Mattsson, D. Migault.

Date: January 2023

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9310

This document specifies the certificate extension for includingNetwork Function Types (NFTypes) for the 5G System in X.509 v3 public key certificates as profiled in RFC 5280.

RFC 9311 Running an IETF Hackathon

Authors: C. Eckel.

Date: September 2022

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9311

IETF Hackathons encourage the IETF community to collaborate on running code related to existing and evolving Internet standards.This document provides a set of practices that have been used for running IETF Hackathons. These practices apply to Hackathons in which both in-person and remote participation are possible, with adaptations for Hackathons that are online only.

RFC 9312 Manageability of the QUIC Transport Protocol

Authors: M. Kühlewind, B. Trammell.

Date: September 2022

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9312

This document discusses manageability of the QUIC transport protocol and focuses on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It is intended as a"user's manual" for the wire image to provide guidance for network operators and equipment vendors who rely on the use of transport- aware network functions.

RFC 9313 Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)

Authors: G. Lencse, J. Palet Martinez, L. Howard, R. Patterson, I. Farrer.

Date: October 2022

Formats: txt pdf xml html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9313

Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. These technologies have their advantages and disadvantages. Depending on existing topology, skills, strategy, and other preferences, one of these technologies may be the most appropriate solution for a network operator.
This document examines the five most prominent IPv4aaS technologies and considers a number of different aspects to provide network operators with an easy-to-use reference to assist in selecting the technology that best suits their needs.

RFC 9314 YANG Data Model for Bidirectional Forwarding Detection (BFD)

Authors: M. Jethanandani, Ed., R. Rahman, Ed., L. Zheng, Ed., S. Pallagatti, G. Mirsky.

Date: September 2022

Formats: txt json pdf xml html

Updates: RFC 9127

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9314

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). This document updates"YANG Data Model for Bidirectional Forwarding Detection (BFD)" (RFC9127).

RFC 9315 Intent-Based Networking - Concepts and Definitions

Authors: A. Clemm, L. Ciavaglia, L. Z. Granville, J. Tantsura.

Date: October 2022

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9315

Intent and Intent-Based Networking are taking the industry by storm.At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions.
This document is a product of the IRTF Network Management ResearchGroup (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes.

RFC 9316 Intent Classification

Authors: C. Li, O. Havel, A. Olariu, P. Martinez-Julia, J. Nobre, D. Lopez.

Date: October 2022

Formats: txt html json xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9316

Intent is an abstract, high-level policy used to operate a network.An intent-based management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their life cycle.
This document mostly discusses the concept of network intents, but other types of intents are also considered. Specifically, this document highlights stakeholder perspectives of intent, methods to classify and encode intent, and the associated intent taxonomy; it also defines relevant intent terms where necessary, provides a foundation for intent-related research, and facilitates solution development.
This document is a product of the IRTF Network Management ResearchGroup (NMRG).

RFC 9317 Operational Considerations for Streaming Media

Authors: J. Holland, A. Begen, S. Dawkins.

Date: October 2022

Formats: txt html xml json pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9317

This document provides an overview of operational networking and transport protocol issues that pertain to the quality of experience(QoE) when streaming video and other high-bitrate media over theInternet.
This document explains the characteristics of streaming media delivery that have surprised network designers or transport experts who lack specific media expertise, since streaming media highlights key differences between common assumptions in existing networking practices and observations of media delivery issues encountered when streaming media over those existing networks.

RFC 9318 IAB Workshop Report: Measuring Network Quality for End-Users

Authors: W. Hardaker, O. Shapira.

Date: October 2022

Formats: txt json xml html pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9318

The Measuring Network Quality for End-Users workshop was held virtually by the Internet Architecture Board (IAB) on September14-16, 2021. This report summarizes the workshop, the topics discussed, and some preliminary conclusions drawn at the end of the workshop.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 9319 The Use of maxLength in the Resource Public Key Infrastructure (RPKI)

Authors: Y. Gilad, S. Goldberg, K. Sriram, J. Snijders, B. Maddison.

Date: October 2022

Formats: txt json html xml pdf

Also: BCP 0185

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9319

This document recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those inRFC 7115. This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and RPKI-basedRoute Origin Validation (RPKI-ROV) in the context of destination- based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted.

RFC 9320 Deterministic Networking (DetNet) Bounded Latency

Authors: N. Finn, J.-Y. Le Boudec, E. Mohammadpour, J. Zhang, B. Varga.

Date: November 2022

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9320

This document presents a timing model for sources, destinations, andDeterministic Networking (DetNet) transit nodes. Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods. The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service.

RFC 9321 Signature Validation Token

Authors: S. Santesson, R. Housley.

Date: October 2022

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9321

Electronic signatures have a limited lifespan with respect to the time period that they can be validated and determined to be authentic. The Signature Validation Token (SVT) defined in this specification provides evidence that asserts the validity of an electronic signature. The SVT is provided by a trusted authority, which asserts that a particular signature was successfully validated according to defined procedures at a certain time. Any future validation of that electronic signature can be satisfied by validating the SVT without any need to also validate the original electronic signature or the associated digital certificates. The SVT supports electronic signatures in Cryptographic Message Syntax (CMS),XML, PDF, and JSON documents.

RFC 9322 In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags

Authors: T. Mizrahi, F. Brockners, S. Bhandari, B. Gafni, M. Spiegel.

Date: November 2022

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9322

In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in packets while they traverse a path between two points in the network. This document defines two new flags in the IOAM Trace Option headers, specifically the Loopback and Active flags.

RFC 9323 A Profile for RPKI Signed Checklists (RSCs)

Authors: J. Snijders, T. Harrison, B. Maddison.

Date: November 2022

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9323

This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure(RPKI) to carry a general-purpose listing of checksums (a'checklist'). The objective is to allow for the creation of an attestation, termed an "RPKI Signed Checklist (RSC)", which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced the RSC.

RFC 9324 Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh

Authors: R. Bush, K. Patel, P. Smith, M. Tinka.

Date: December 2022

Formats: txt json html xml pdf

Updates: RFC 8481

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9324

A BGP speaker performing policy based on the Resource Public KeyInfrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data. This document updates RFC8481 by describing how to avoid doing so by either keeping a fullAdj-RIB-In or saving paths dropped due to ROV (Route OriginValidation) so they may be reevaluated with respect to new RPKI data.

RFC 9325 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

Authors: Y. Sheffer, P. Saint-Andre, T. Fossati.

Date: November 2022

Formats: txt json xml pdf html

Obsoletes: RFC 7525

Updates: RFC 5288, RFC 6066

Also: BCP 0195

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9325

Transport Layer Security (TLS) and Datagram Transport Layer Security(DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.
RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.

RFC 9326 In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting

Authors: H. Song, B. Gafni, F. Brockners, S. Bhandari, T. Mizrahi.

Date: November 2022

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9326

In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information.Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAMDirect Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document.

RFC 9327 Control Messages Protocol for Use with Network Time Protocol Version 4

Authors: B. Haberman, Ed..

Date: November 2022

Formats: txt pdf html xml json

Status: HISTORIC

DOI: 10.17487/RFC 9327

This document describes the structure of the control messages that were historically used with the Network Time Protocol (NTP) before the advent of more modern control and management approaches. These control messages have been used to monitor and control the NTP application running on any IP network attached computer. The information in this document was originally described in Appendix B of RFC 1305. The goal of this document is to provide an updated description of the control messages described in RFC 1305 in order to conform with the updated NTP specification documented in RFC 5905.
The publication of this document is not meant to encourage the development and deployment of these control messages. This document is only providing a current reference for these control messages given the current status of RFC 1305.

RFC 9328 RTP Payload Format for Versatile Video Coding (VVC)

Authors: S. Zhao, S. Wenger, Y. Sanchez, Y.-K. Wang, M. M Hannuksela.

Date: December 2022

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9328

This memo describes an RTP payload format for the Versatile VideoCoding (VVC) specification, which was published as both ITU-TRecommendation H.266 and ISO/IEC International Standard 23090-3. VVC was developed by the Joint Video Experts Team (JVET). The RTP payload format allows for packetization of one or more NetworkAbstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications.

RFC 9329 TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets

Authors: T. Pauly, V. Smyslov.

Date: November 2022

Formats: txt pdf xml json html

Obsoletes: RFC 8229

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9329

This document describes a method to transport Internet Key ExchangeProtocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association (SA) establishment and EncapsulatingSecurity Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.
TCP encapsulation for IKE and IPsec was defined in RFC 8229. This document clarifies the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents obsoletes RFC 8229.

RFC 9330 Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture

Authors: B. Briscoe, Ed., K. De Schepper, M. Bagnulo, G. White.

Date: January 2023

Formats: txt xml json pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9330

This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput.
The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance.

RFC 9331 The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)

Authors: K. De Schepper, B. Briscoe, Ed..

Date: January 2023

Formats: txt xml json pdf html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9331

This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S).L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP- like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load.
The L4S identifier defined in this document distinguishes L4S from'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic.This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately.

RFC 9332 Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)

Authors: K. De Schepper, B. Briscoe, Ed., G. White.

Date: January 2023

Formats: txt html json pdf xml

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9332

This specification defines a framework for coupling the Active QueueManagement (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for theInternet to transition from the scaling problems of standard TCP-Reno-friendly ('Classic') congestion controls to the family of'Scalable' congestion controls. These are designed for consistently very low queuing latency, very low congestion loss, and scaling of per-flow throughput by using Explicit Congestion Notification (ECN) in a modified way. Until the Coupled Dual Queue (DualQ), theseScalable L4S congestion controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres.
This specification first explains how a Coupled DualQ works. It then gives the normative requirements that are necessary for it to work well. All this is independent of which two AQMs are used, but pseudocode examples of specific AQMs are given in appendices.

RFC 9333 Minimal IP Encapsulating Security Payload (ESP)

Authors: D. Migault, T. Guggemos.

Date: January 2023

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9333

This document describes the minimal properties that an IPEncapsulating Security Payload (ESP) implementation needs to meet to remain interoperable with the standard ESP as defined in RFC 4303.Such a minimal version of ESP is not intended to become a replacement of ESP in RFC 4303. Instead, a minimal implementation is expected to be optimized for constrained environments while remaining interoperable with implementations of ESP. In addition, this document provides some considerations for implementing minimal ESP in a constrained environment, such as limiting the number of flash writes, handling frequent wakeup and sleep states, limiting wakeup time, and reducing the use of random generation.
This document does not update or modify RFC 4303. It provides a compact description of how to implement the minimal version of that protocol. RFC 4303 remains the authoritative description.

RFC 9334 Remote ATtestation procedureS (RATS) Architecture

Authors: H. Birkholz, D. Thaler, M. Richardson, N. Smith, W. Pan.

Date: January 2023

Formats: txt json pdf html xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9334

In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims.It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.

RFC 9335 Completely Encrypting RTP Header Extensions and Contributing Sources

Authors: J. Uberti, C. Jennings, S. Murillo.

Date: January 2023

Formats: txt json pdf xml html

Updates: RFC 3711

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9335

While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations.
This document updates RFC 3711, the SRTP specification, and definesCryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment.

RFC 9336 X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing

Authors: T. Ito, T. Okubo, S. Turner.

Date: December 2022

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9336

RFC 5280 specifies several extended key purpose identifiers(KeyPurposeIds) for X.509 certificates. This document defines a general-purpose Document-Signing KeyPurposeId for inclusion in theExtended Key Usage (EKU) extension of X.509 public key certificates.Document-Signing applications may require that the EKU extension be present and that a Document-Signing KeyPurposeId be indicated in order for the certificate to be acceptable to that Document-Signing application.

RFC 9337 Generating Password-Based Keys Using the GOST Algorithms

Authors: E. Karelina, Ed..

Date: December 2022

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9337

This document specifies how to use "PKCS #5: Password-BasedCryptography Specification Version 2.1" (RFC 8018) to generate a symmetric key from a password in conjunction with the Russian national standard GOST algorithms.
PKCS #5 applies a Pseudorandom Function (PRF) -- a cryptographic hash, cipher, or Hash-Based Message Authentication Code (HMAC) -- to the input password along with a salt value and repeats the process many times to produce a derived key.
This specification has been developed outside the IETF. The purpose of publication being to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used here.

RFC 9338 CBOR Object Signing and Encryption (COSE): Countersignatures

Authors: J. Schaad.

Date: December 2022

Formats: txt xml pdf json html

Updates: RFC 9052

Also: STD 0096

Status: INTERNET STANDARD

DOI: 10.17487/RFC 9338

Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing andEncryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC9052.

RFC 9339 OSPF Reverse Metric

Authors: K. Talaulikar, Ed., P. Psenak, H. Johnston.

Date: December 2022

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9339

This document specifies the extensions to OSPF that enable a router to use Link-Local Signaling (LLS) to signal the metric that receivingOSPF neighbor(s) should use for a link to the signaling router. When used on the link to the signaling router, the signaling of this reverse metric (RM) allows a router to influence the amount of traffic flowing towards itself. In certain use cases, this enables routers to maintain symmetric metrics on both sides of a link between them.

RFC 9340 Architectural Principles for a Quantum Internet

Authors: W. Kozlowski, S. Wehner, R. Van Meter, B. Rijsman, A. S. Cacciapuoti, M. Caleffi, S. Nagayama.

Date: March 2023

Formats: txt html json pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9340

The vision of a quantum internet is to enhance existing Internet technology by enabling quantum communication between any two points on Earth. To achieve this goal, a quantum network stack should be built from the ground up to account for the fundamentally new properties of quantum entanglement. The first quantum entanglement networks have been realised, but there is no practical proposal for how to organise, utilise, and manage such networks. In this document, we attempt to lay down the framework and introduce some basic architectural principles for a quantum internet. This is intended for general guidance and general interest. It is also intended to provide a foundation for discussion between physicists and network specialists. This document is a product of the QuantumInternet Research Group (QIRG).

RFC 9341 Alternate-Marking Method

Authors: G. Fioccola, Ed., M. Cociglio, G. Mirsky, T. Mizrahi, T. Zhou.

Date: December 2022

Formats: txt html pdf xml json

Obsoletes: RFC 8321

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9341

This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application.This document obsoletes RFC 8321.

RFC 9342 Clustered Alternate-Marking Method

Authors: G. Fioccola, Ed., M. Cociglio, A. Sapio, R. Sisto, T. Zhou.

Date: December 2022

Formats: txt xml pdf json html

Obsoletes: RFC 8889

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9342

This document generalizes and expands the Alternate-Marking methodology to measure any kind of unicast flow whose packets can follow several different paths in the network; this can result in a multipoint-to-multipoint network. The network clustering approach is presented and, for this reason, the technique described here is called "Clustered Alternate Marking". This document obsoletes RFC8889.

RFC 9343 IPv6 Application of the Alternate-Marking Method

Authors: G. Fioccola, T. Zhou, M. Cociglio, F. Qin, R. Pang.

Date: December 2022

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9343

This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and DestinationOptions Header.

RFC 9344 CCNinfo: Discovering Content and Network Information in Content-Centric Networks

Authors: H. Asaeda, A. Ooka, X. Shao.

Date: February 2023

Formats: txt xml pdf html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9344

This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache inContent-Centric Networks (CCNs). CCNinfo investigates 1) the CCN routing path information per name prefix, 2) the Round-Trip Time(RTT) between the content forwarder and the consumer, and 3) the states of in-network cache per name prefix. CCNinfo is useful to understand and debug the behavior of testbed networks and other experimental deployments of CCN systems.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). This document represents the consensus view of ICNRG and has been reviewed extensively by several members of theICN community and the RG. The authors and RG chairs approve of the contents. The document is sponsored under the IRTF, is not issued by the IETF, and is not an IETF standard. This is an experimental protocol and the specification may change in the future.

RFC 9345 Delegated Credentials for TLS and DTLS

Authors: R. Barnes, S. Iyengar, N. Sullivan, E. Rescorla.

Date: July 2023

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9345

The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations.For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by theCertification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification.

RFC 9346 IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering

Authors: M. Chen, L. Ginsberg, S. Previdi, D. Xiaodong.

Date: February 2023

Formats: txt json pdf xml html

Obsoletes: RFC 5316

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9346

This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering(TE) for multiple Autonomous Systems (ASes). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS is proposed or defined in this document.
This document builds on RFC 5316 by adding support for IPv6-only operation.
This document obsoletes RFC 5316.

RFC 9347 Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)

Authors: C. Hopps.

Date: January 2023

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9347

This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in EncapsulatingSecurity Payload (ESP). This new payload type can be used for various purposes, such as decreasing encapsulation overhead for smallIP packets; however, the focus in this document is to enhance IPTraffic Flow Security (IP-TFS) by adding Traffic Flow Confidentiality(TFC) to encrypted IP-encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-size, constant-send-rate IPsec tunnel. The solution allows for congestion control, as well as nonconstant send-rate usage.

RFC 9348 A YANG Data Model for IP Traffic Flow Security

Authors: D. Fedyk, C. Hopps.

Date: January 2023

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9348

This document describes a YANG module for the management of IPTraffic Flow Security (IP-TFS) additions to Internet Key ExchangeProtocol version 2 (IKEv2) and IPsec.

RFC 9349 Definitions of Managed Objects for IP Traffic Flow Security

Authors: D. Fedyk, E. Kinzie.

Date: January 2023

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9349

This document describes managed objects for the management of IPTraffic Flow Security additions to Internet Key Exchange ProtocolVersion 2 (IKEv2) and IPsec. This document provides a read-only version of the objects defined in the YANG module for the same purpose, which is in "A YANG Data Model for IP Traffic Flow Security"(RFC 9348).

RFC 9350 IGP Flexible Algorithm

Authors: P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. Gulko.

Date: February 2023

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9350

IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.

RFC 9351 Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement

Authors: K. Talaulikar, Ed., P. Psenak, S. Zandi, G. Dawra.

Date: February 2023

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9351

Flexible Algorithm is a solution that allows some routing protocols(e.g., OSPF and IS-IS) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition(FAD). This definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding.
Border Gateway Protocol - Link State (BGP-LS) enables the collection of various topology information from the network. This document defines extensions to the BGP-LS address family to advertise the FAD as a part of the topology information from the network.

RFC 9352 IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane

Authors: P. Psenak, Ed., C. Filsfils, A. Bashandy, B. Decraene, Z. Hu.

Date: February 2023

Formats: txt pdf xml json html

Updates: RFC 7370

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9352

The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane.
This document updates RFC 7370 by modifying an existing registry.

RFC 9353 IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED)

Authors: D. Lopez, Q. Wu, D. Dhody, Q. Ma, D. King.

Date: January 2023

Formats: txt json pdf xml html

Updates: RFC 5088, RFC 5089, RFC 8231, RFC 8306

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9353

When a Path Computation Element (PCE) is a Label Switching Router(LSR) or a server participating in the Interior Gateway Protocol(IGP), its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE Discovery(PCED) (RFCs 5088 and 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS, respectively. However, these specifications lack a method to advertise Path Computation Element Communication Protocol (PCEP) security (e.g., Transport Layer Security (TLS) and TCP AuthenticationOption (TCP-AO)) support capability.
This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV that can be announced as an attribute in the IGP advertisement to distribute PCEP security support information. In addition, this document updates RFCs 5088 and 5089 to allow advertisement of a KeyID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.This document also updates RFCs 8231 and 8306.

RFC 9354 Transmission of IPv6 Packets over Power Line Communication (PLC) Networks

Authors: J. Hou, B. Liu, Y-G. Hong, X. Tang, C. Perkins.

Date: January 2023

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9354

Power Line Communication (PLC), namely using electric power lines for indoor and outdoor communications, has been widely applied to supportAdvanced Metering Infrastructure (AMI), especially smart meters for electricity. The existing electricity infrastructure facilitates the expansion of PLC deployments due to its potential advantages in terms of cost and convenience. Moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications.This document describes how IPv6 packets are transported over constrained PLC networks, such as those described in ITU-T G.9903,IEEE 1901.1, and IEEE 1901.2.

RFC 9355 OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode

Authors: K. Talaulikar, Ed., P. Psenak, A. Fu, M. Rajesh.

Date: February 2023

Formats: txt pdf xml html json

Updates: RFC 2328

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9355

This document specifies the extensions to OSPF that enable an OSPF router to signal the requirement for a Bidirectional ForwardingDetection (BFD) session prior to adjacency formation. Link-LocalSignaling (LLS) is used to advertise the requirement for strict-modeBFD session establishment for an OSPF adjacency. If both OSPF neighbors advertise BFD strict-mode, adjacency formation will be blocked until a BFD session has been successfully established.
This document updates RFC 2328 by augmenting the OSPF neighbor state machine with a check for BFD session up before progression from Init to 2-Way state when operating in OSPF BFD strict-mode.

RFC 9356 Advertising Layer 2 Bundle Member Link Attributes in OSPF

Authors: K. Talaulikar, Ed., P. Psenak.

Date: January 2023

Formats: txt json html xml pdf

Updates: RFC 9085

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9356

There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the L3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links that comprise the L2 interface bundle, link attribute information for the bundle members is required.
This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The document also specifies the advertisement of these OSPF extensions via the BorderGateway Protocol - Link State (BGP-LS) and thereby updates RFC 9085.

RFC 9357 Label Switched Path (LSP) Object Flag Extension for Stateful PCE

Authors: Q. Xiong.

Date: February 2023

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9357

RFC 8231 describes a set of extensions to the Path ComputationElement Communication Protocol (PCEP) to enable stateful control ofMPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the extensions is the LSP object, which includes a Flag field with a length of 12 bits. However, all bits of the Flag field have already been assigned.
This document defines a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended Flag field.

RFC 9358 Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks

Authors: Y. Lee, H. Zheng, D. Ceccarelli.

Date: February 2023

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9358

This document describes how to extend the Path Computation ElementCommunication Protocol (PCEP) association mechanism introduced by RFC8697 to further associate sets of Label Switched Paths (LSPs) with a higher-level structure such as a Virtual Network (VN) requested by a customer or application. This extended association mechanism can be used to facilitate control of a VN using the PCE architecture.

RFC 9359 Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities

Authors: X. Min, G. Mirsky, L. Bo.

Date: April 2023

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9359

This document describes a generic format for use in echo request/ reply mechanisms, which can be used within an IOAM-Domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The generic format is intended to be used with a variety of data planes such as IPv6,MPLS, Service Function Chain (SFC), and Bit Index ExplicitReplication (BIER).

RFC 9360 CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates

Authors: J. Schaad.

Date: February 2023

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9360

The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates.

RFC 9361 ICANN Trademark Clearinghouse (TMCH) Functional Specifications

Authors: G. Lozano.

Date: March 2023

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9361

This document describes the requirements, the architecture, and the interfaces between the ICANN Trademark Clearinghouse (TMCH) andDomain Name Registries, as well as between the ICANN TMCH and DomainName Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods.

RFC 9362 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission

Authors: M. Boucadair, J. Shallow.

Date: February 2023

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9362

This document specifies new DDoS Open Threat Signaling (DOTS) signal channel configuration parameters that can be negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 ConstrainedApplication Protocol (CoAP) options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well as support for faster recovery should any of the blocks get lost in transmission (especially during DDoS attacks).
Also, this document defines a YANG data model for representing these new DOTS signal channel configuration parameters. This model augments the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC 9132.

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.

RFC 9364 DNS Security Extensions (DNSSEC)

Authors: P. Hoffman.

Date: February 2023

Formats: txt html xml json pdf

Also: BCP 0237

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9364

This document describes the DNS Security Extensions (commonly called"DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects ofDNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication ofDNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.

RFC 9365 IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases

Authors: J. Jeong, Ed..

Date: March 2023

Formats: txt html xml json pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9365

This document discusses the problem statement and use cases ofIPv6-based vehicular networking for Intelligent TransportationSystems (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, forIPv6-based vehicular networks, it makes a gap analysis of currentIPv6 protocols (e.g., IPv6 Neighbor Discovery, mobility management, as well as security and privacy).

RFC 9366 Multiple SIP Reason Header Field Values

Authors: R. Sparks.

Date: March 2023

Formats: txt json pdf xml html

Updates: RFC 3326

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9366

The SIP Reason header field as defined in RFC 3326 allows only oneReason value per protocol value. Experience with more recently defined protocols shows it is useful to allow multiple values with the same protocol value. This document updates RFC 3326 to allow multiple values for an indicated registered protocol when that protocol defines what the presence of multiple values means.

RFC 9367 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3

Authors: S. Smyshlyaev, Ed., E. Alekseev, E. Griboedova, A. Babueva, L. Nikiforova.

Date: February 2023

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9367

The purpose of this document is to make the Russian cryptographic standards available to the Internet community for their implementation in the Transport Layer Security (TLS) Protocol Version1.3.
This document defines the cipher suites, signature schemes, and key exchange mechanisms for using Russian cryptographic standards, calledGOST algorithms, with TLS Version 1.3. Additionally, this document specifies a profile of TLS 1.3 with GOST algorithms to facilitate interoperable implementations. The IETF has not endorsed the cipher suites, signature schemes, or key exchange mechanisms described in this document.

RFC 9368 Compatible Version Negotiation for QUIC

Authors: D. Schinazi, E. Rescorla.

Date: May 2023

Formats: txt html pdf xml json

Updates: RFC 8999

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9368

QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999.

RFC 9369 QUIC Version 2

Authors: M. Duke.

Date: May 2023

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9369

This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.
Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as aStandards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks.

RFC 9370 Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: CJ. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. Van Geest, O. Garcia-Morchon, V. Smyslov.

Date: May 2023

Formats: txt html xml pdf json

Updates: RFC 7296

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9370

This document describes how to extend the Internet Key ExchangeProtocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association(SA) setup.
This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.
This document updates RFC 7296 by renaming a Transform Type 4 from"Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-HellmanGroup Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to "Transform Type 4 - Key ExchangeMethod Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2.

RFC 9371 Registration Procedures for Private Enterprise Numbers (PENs)

Authors: A. Baber, P. Hoffman.

Date: March 2023

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9371

This document describes how Private Enterprise Numbers (PENs) are registered by IANA. It shows how to request a new PEN and how to modify a current PEN. It also gives a brief overview of PEN uses.

RFC 9372 L-Band Digital Aeronautical Communications System (LDACS)

Authors: N. Mäurer, Ed., T. Gräupl, Ed., C. Schmitt, Ed..

Date: March 2023

Formats: txt json pdf html xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9372

This document gives an overview of the L-band Digital AeronauticalCommunications System (LDACS) architecture, which provides a secure, scalable, and spectrum-efficient terrestrial data link for civil aviation. LDACS is a scheduled and reliable multi-application cellular broadband system with support for IPv6. It is part of a larger shift of flight guidance communication moving to IP-based communication. High reliability and availability of IP connectivity over LDACS, as well as security, are therefore essential. The intent of this document is to introduce LDACS to the IETF community, raise awareness on related activities inside and outside of the IETF, and to seek expertise in shaping the shift of aeronautics to IP.

RFC 9373 EdDSA Value for IPSECKEY

Authors: R. Moskowitz, T. Kivinen, M. Richardson.

Date: March 2023

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9373

This document assigns a value for Edwards-Curve Digital SignatureAlgorithm (EdDSA) Public Keys to the "IPSECKEY Resource RecordParameters" registry.

RFC 9374 DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)

Authors: R. Moskowitz, S. Card, A. Wiethuechter, A. Gurtov.

Date: March 2023

Formats: txt html pdf xml json

Updates: RFC 7343, RFC 7401

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9374

This document describes the use of Hierarchical Host Identity Tags(HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification(UAS RID) and tracking.
Within the context of RID, HHITs will be called DRIP Entity Tags(DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third- party identifier endorsement.
This document updates RFCs 7343 and 7401.

RFC 9375 A YANG Data Model for Network and VPN Service Performance Monitoring

Authors: B. Wu, Ed., Q. Wu, Ed., M. Boucadair, Ed., O. Gonzalez de Dios, B. Wen.

Date: April 2023

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9375

The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers.

RFC 9376 Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network

Authors: Q. Wang, Ed., R. Valiveti, Ed., H. Zheng, Ed., H. van Helvoort, S. Belotti.

Date: March 2023

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9376

This document examines the applicability of using existing GMPLS routing and signaling mechanisms to set up Optical Data Unit-k (ODUk)Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of ITU-T Recommendation G.709.

RFC 9377 IS-IS Flood Reflection

Authors: T. Przygienda, Ed., C. Bowers, Y. Lee, A. Sharma, R. White.

Date: April 2023

Formats: txt xml json pdf html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9377

This document describes a backward-compatible, optional IS-IS extension that allows the creation of IS-IS flood reflection topologies. Flood reflection permits topologies in whichIS-IS Level 1 (L1) areas provide transit-forwarding for IS-IS Level 2(L2) areas using all available L1 nodes internally. It accomplishes this by creating L2 flood reflection adjacencies within each L1 area.Those adjacencies are used to flood L2 Link State Protocol Data Units(LSPs) and are used in the L2 Shortest Path First (SPF) computation.However, they are not ordinarily utilized for forwarding within the flood reflection cluster. This arrangement gives the L2 topology significantly better scaling properties than prevalently used flat designs. As an additional benefit, only those routers directly participating in flood reflection are required to support the feature. This allows for incremental deployment of scalable L1 transit areas in an existing, previously flat network design, without the necessity of upgrading all routers in the network.

RFC 9378 In Situ Operations, Administration, and Maintenance (IOAM) Deployment

Authors: F. Brockners, Ed., S. Bhandari, Ed., D. Bernier, T. Mizrahi, Ed..

Date: April 2023

Formats: txt xml html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9378

In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document provides a framework for IOAM deployment and provides IOAM deployment considerations and guidance.

RFC 9380 Hashing to Elliptic Curves

Authors: A. Faz-Hernandez, S. Scott, N. Sullivan, R. S. Wahby, C. A. Wood.

Date: August 2023

Formats: txt html json xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9380

This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

RFC 9381 Verifiable Random Functions (VRFs)

Authors: S. Goldberg, L. Reyzin, D. Papadopoulos, J. Včelák.

Date: August 2023

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9381

A Verifiable Random Function (VRF) is the public key version of a keyed cryptographic hash. Only the holder of the secret key can compute the hash, but anyone with the public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies VRF constructions based on RSA and elliptic curves that are secure in the cryptographic random oracle model.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

RFC 9382 SPAKE2, a Password-Authenticated Key Exchange

Authors: W. Ladd.

Date: September 2023

Formats: txt pdf json xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9382

This document describes SPAKE2, which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password. This method is compatible with any group, is computationally efficient, and has a security proof. This document predated the Crypto Forum Research Group (CFRG) password- authenticated key exchange (PAKE) competition, and it was not selected; however, given existing use of variants in Kerberos and other applications, it was felt that publication was beneficial.Applications that need a symmetric PAKE, but are unable to hash onto an elliptic curve at execution time, can use SPAKE2. This document is a product of the Crypto Forum Research Group in the InternetResearch Task Force (IRTF).

RFC 9383 SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol

Authors: T. Taubert, C. A. Wood.

Date: September 2023

Formats: txt pdf json xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9383

This document describes SPAKE2+, a Password-Authenticated KeyExchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime-order group, and computationally efficient.
This document was produced outside of the IETF and IRTF and represents the opinions of the authors. Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement of SPAKE2+ by the IETF or IRTF.

RFC 9384 A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD)

Authors: J. Haas.

Date: March 2023

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9384

The Bidirectional Forwarding Detection (BFD) protocol (RFC 5880) is used to detect loss of connectivity between two forwarding engines, typically with low latency. BFD is leveraged by routing protocols, including the Border Gateway Protocol (BGP), to bring down routing protocol connections more quickly than the original protocol timers.
This document defines a subcode for the BGP Cease NOTIFICATION message (Section 6.7 of RFC 4271) for use when a BGP connection is being closed due to a BFD session going down.

RFC 9385 Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: V. Smyslov.

Date: May 2023

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9385

This document defines a set of cryptographic transforms for use in the Internet Key Exchange Protocol version 2 (IKEv2). The transforms are based on Russian cryptographic standard algorithms (called "GOST" algorithms). Use of GOST ciphers in IKEv2 is defined in RFC 9227.This document aims to define the use of GOST algorithms for the rest of the cryptographic transforms used in IKEv2.
This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used in this document.

RFC 9386 IPv6 Deployment Status

Authors: G. Fioccola, P. Volpato, J. Palet Martinez, G. Mishra, C. Xie.

Date: April 2023

Formats: txt json xml pdf html

Obsoletes: RFC 6036

Status: INFORMATIONAL

DOI: 10.17487/RFC 9386

This document provides an overview of the status of IPv6 deployment in 2022. Specifically, it looks at the degree of adoption of IPv6 in the industry, analyzes the remaining challenges, and proposes further investigations in areas where the industry has not yet taken a clear and unified approach in the transition to IPv6. It obsoletes RFC6036.

RFC 9387 Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry

Authors: Y. Hayashi, M. Chen, L. Su.

Date: April 2023

Formats: txt json xml html pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9387

DDoS Open Threat Signaling (DOTS) telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS attack mitigation techniques in a network. This document presents sample use cases for DOTS telemetry. It discusses what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques.

RFC 9388 Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union

Authors: N. Sopher, S. Mishra.

Date: July 2023

Formats: txt html json xml pdf

Updates: RFC 8008

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9388

Open Caching architecture is a use case of Content Delivery NetworkInterconnection (CDNI) in which the commercial Content DeliveryNetwork (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). RFC 8006 defines footprint types that are used for footprint objects as part of the Metadata interface (MI). The footprint types are also used for the Footprint& Capabilities Advertisement interface (FCI) as defined in RFC 8008.This document defines two new footprint types. The first footprint type defined is an ISO 3166-2 country subdivision code. Defining this country subdivision code improves granularity for delegation as compared to the ISO 3166-1 country code footprint type defined in RFC8006. The ISO 3166-2 country subdivision code is also added as a new entity domain type in the "ALTO Entity Domain Types" registry defined in Section 7.4 of RFC 9241. The second footprint type defines a footprint union to aggregate footprint objects. This allows for additive semantics over the narrowing semantics defined in Appendix B of RFC 8008 and therefore updates RFC 8008. The two new footprint types are based on the requirements raised by Open Caching but are also applicable to CDNI use cases in general.

RFC 9389 Nominating Committee Eligibility

Authors: M. Duke.

Date: April 2023

Formats: txt html xml pdf json

Obsoletes: RFC 8788, RFC 8989

Updates: RFC 8713

Also: BCP 0010

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9389

The IETF Nominating Committee (NomCom) appoints candidates to severalIETF leadership committees. RFC 8713 provides criteria for NomCom membership that attempt to ensure NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in-person meetings. In 2020 and 2021, theIETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility. This document updates RFC 8713 by defining a new set of eligibility criteria from first principles, with consideration to the increased salience of remote attendance. This document obsoletesRFCs 8788 and 8989.

RFC 9390 Diameter Group Signaling

Authors: M. Jones, M. Liebsch, L. Morand.

Date: April 2023

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9390

In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases can result in many thousands of command exchanges enforcing the same operation on each session in the group. In order to reduce signaling, it is desirable to enable bulk operations on all (or part of) the sessions managed by aDiameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization.

RFC 9391 Static Context Header Compression over Narrowband Internet of Things

Authors: E. Ramos, A. Minaburo.

Date: April 2023

Formats: txt html pdf json xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9391

This document describes Static Context Header Compression and fragmentation (SCHC) specifications, RFCs 8724 and 8824, in combination with the 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT).
This document has two parts: one normative part that specifies the use of SCHC over NB-IoT and one informational part that recommends some values if 3GPP wants to use SCHC inside their architectures.

RFC 9392 Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences

Authors: C. Perkins.

Date: April 2023

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9392

This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and the suitability ofRTCP for implementing congestion control for unicast multimedia applications.

RFC 9393 Concise Software Identification Tags

Authors: H. Birkholz, J. Fitzgerald-McKay, C. Schmidt, D. Waltermire.

Date: June 2023

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9393

ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format.

RFC 9394 IMAP PARTIAL Extension for Paged SEARCH and FETCH

Authors: A. Melnikov, A. P. Achuthan, V. Nagulakonda, L. Alves.

Date: June 2023

Formats: txt xml html pdf json

Updates: RFC 4731, RFC 5267

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9394

The PARTIAL extension of the Internet Message Access Protocol (seeRFCs 3501 and 9051) allows clients to limit the number of SEARCH results returned, as well as to perform incremental (paged) searches.This also helps servers to optimize resource usage when performing searches.
This document extends the PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions betweenRFC 5267 and RFCs 4731 and 9051.
This document updates RFCs 4731 and 5267.

RFC 9395 Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms

Authors: P. Wouters, Ed..

Date: April 2023

Formats: txt xml pdf html json

Updates: RFC 8221, RFC 8247

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9395

Internet Key Exchange Version 1 (IKEv1) has been deprecated, and RFCs2407, 2408, and 2409 have been moved to Historic status. This document updates RFCs 8221 and 8247 to reflect the usage guidelines of old algorithms that are associated with IKEv1 and are not specified or commonly implemented for IKEv2. This document further updates the IANA registries for IKEv2 "Transform Type Values" by adding a "Status" column where the deprecation status can be listed.

RFC 9396 OAuth 2.0 Rich Authorization Requests

Authors: T. Lodderstedt, J. Richer, B. Campbell.

Date: May 2023

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9396

This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages.

RFC 9397 Trusted Execution Environment Provisioning (TEEP) Architecture

Authors: M. Pei, H. Tschofenig, D. Thaler, D. Wheeler.

Date: July 2023

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9397

A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE.

RFC 9398 A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices

Authors: H. Zhao, X. Liu, Y. Liu, M. Panchanathan, M. Sivakumar.

Date: May 2023

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9398

This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) or MulticastListener Discovery (MLD) Proxy devices. The YANG module in this document conforms to the Network Management Datastore Architecture(NMDA).

RFC 9399 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates

Authors: S. Santesson, R. Housley, T. Freeman, L. Rosenthol.

Date: May 2023

Formats: txt html pdf xml json

Obsoletes: RFC 3709, RFC 6170

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9399

This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates.This document obsoletes RFCs 3709 and 6170.

RFC 9400 Guidelines for the Organization of Fully Online Meetings

Authors: M. Kühlewind, M. Duke.

Date: June 2023

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9400

This document provides guidelines for the planning and organization of fully online meetings, regarding the number, length, and composition of sessions on the meeting agenda. These guidelines are based on the experience gained by holding online meetings during theCOVID-19 pandemic in 2020 and 2021.

RFC 9401 The Addition of the Death (DTH) Flag to TCP

Authors: S. Toyosawa.

Date: 1 April 2023

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9401

This memo specifies the incorporation of Death (DTH) flag to TCP, including DTH's use of one bit in the TCP header. The flag is designed to make TCP session narratives smooth and attractive.

RFC 9402 Concat Notation

Authors: M. Basaglia, J. Bernards, J. Maas.

Date: 1 April 2023

Formats: txt json pdf html xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9402

This document defines the Concat notation: a text-based language used to describe pictures and videos whose subject includes cats, containers, and their interactions.

RFC 9403 A YANG Data Model for RIB Extensions

Authors: A. Lindem, Y. Qu.

Date: November 2023

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9403

A Routing Information Base (RIB) is a list of routes and their corresponding administrative data and operational state.
RFC 8349 defines the basic building blocks for the RIB data model, and this model augments it to support multiple next hops (aka paths) for each route as well as additional attributes.

RFC 9404 JSON Meta Application Protocol (JMAP) Blob Management Extension

Authors: B. Gondwana, Ed..

Date: August 2023

Formats: txt html json pdf xml

Updates: RFC 8620

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9404

The JSON Meta Application Protocol (JMAP) base protocol (RFC 8620) provides the ability to upload and download arbitrary binary data viaHTTP POST and GET on a defined endpoint. This binary data is called a "blob".
This extension adds additional ways to create and access blobs by making inline method calls within a standard JMAP request.
This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types.

RFC 9405 AI Sarcasm Detection: Insult Your AI without Offending It

Authors: C. GPT, R. L. Barnes, Ed..

Date: 1 April 2023

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9405

This RFC proposes a framework for detecting sarcasm in AI systems and provides guidelines for using sarcasm without causing offense. By training AI systems to identify linguistic patterns that indicate sarcasm, we can improve their understanding of human communication.The guidelines offer a lighthearted approach to using sarcasm in a way that is both effective and respectful, without crossing the line into offensive language.

RFC 9406 HyStart++: Modified Slow Start for TCP

Authors: P. Balasubramanian, Y. Huang, M. Olson.

Date: May 2023

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9406

This document describes HyStart++, a simple modification to the slow start phase of congestion control algorithms. Slow start can overshoot the ideal send rate in many cases, causing high packet loss and poor performance. HyStart++ uses increase in round-trip delay as a heuristic to find an exit point before possible overshoot. It also adds a mitigation to prevent jitter from causing premature slow start exit.

RFC 9407 Tetrys: An On-the-Fly Network Coding Protocol

Authors: J. Detchart, E. Lochin, J. Lacan, V. Roca.

Date: June 2023

Formats: txt xml pdf json html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9407

This document describes Tetrys, which is an on-the-fly network coding protocol that can be used to transport delay-sensitive and loss- sensitive data over a lossy network. Tetrys may recover from erasures within an RTT-independent delay thanks to the transmission of coded packets. This document is a record of the experience gained by the authors while developing and testing the Tetrys protocol in real conditions.
This document is a product of the Coding for Efficient NetWorkCommunications Research Group (NWCRG). It conforms to the NWCRG taxonomy described in RFC 8406.

RFC 9408 A YANG Network Data Model for Service Attachment Points (SAPs)

Authors: M. Boucadair, Ed., O. Gonzalez de Dios, S. Barguil, Q. Wu, V. Lopez.

Date: June 2023

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9408

This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers(including peer networks).
This document augments the 'ietf-network' data model defined in RFC8345 by adding the concept of Service Attachment Points (SAPs). TheSAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual PrivateNetwork (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) andNetwork-to-Network Interface (NNI) are supported in the SAP data model.

RFC 9409 The 'sip-trunking-capability' Link Relation Type

Authors: K. Inamdar, S. Narayanan, D. Engi, G. Salgueiro.

Date: July 2023

Formats: txt xml html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9409

This Informational document defines the 'sip-trunking-capability' link relation type that may be used by an enterprise telephonySession Initiation Protocol (SIP) network to retrieve a SIP trunking capability set document, which contains the capabilities and configuration requirements of an Internet Telephony Service Provider(ITSP). These technical requirements allow for seamless peering between SIP-based enterprise telephony networks and the ITSP.

RFC 9410 Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR)

Authors: C. Wendt.

Date: July 2023

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9410

This document extends the current error-handling procedures for mapping of verification failure reasons to 4xx codes for SecureTelephone Identity Revisited (STIR) and the Authenticated IdentityManagement in the Session Initiation Protocol (SIP). It extends the ability to use the Reason header field as an option for conveying an error associated with an Identity header field to the upstream authentication service when local policy dictates that the call should continue in the presence of a verification failure. This document also defines procedures that enable a failure reason to be mapped to a specific Identity header field for scenarios that use multiple Identity header fields, where some may have errors and others may not. The handling of those situations is also defined.

RFC 9411 Benchmarking Methodology for Network Security Device Performance

Authors: B. Balarajah, C. Rossenhoevel, B. Monkman.

Date: March 2023

Formats: txt html pdf xml json

Obsoletes: RFC 3511

Status: INFORMATIONAL

DOI: 10.17487/RFC 9411

This document provides benchmarking terminology and methodology for next-generation network security devices, including next-generation firewalls (NGFWs) and next-generation intrusion prevention systems(NGIPSs). The main areas covered in this document are test terminology, test configuration parameters, and benchmarking methodology for NGFWs and NGIPSs. (It is assumed that readers have a working knowledge of these devices and the security functionality they contain.) This document aims to improve the applicability, reproducibility, and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 security- centric network application use cases. As a result, this document makes RFC 3511 obsolete.

RFC 9412 The ORIGIN Extension in HTTP/3

Authors: M. Bishop.

Date: June 2023

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9412

The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it needs to be separately registered. This document describes theORIGIN frame for HTTP/3.

RFC 9413 Maintaining Robust Protocols

Authors: M. Thomson, D. Schinazi.

Date: June 2023

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9413

The main goal of the networking standards process is to enable the long-term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem.
The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls.

RFC 9414 Unfortunate History of Transient Numeric Identifiers

Authors: F. Gont, I. Arce.

Date: July 2023

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9414

This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols and how the security and privacy properties of such protocols have been affected as a result of it. It provides empirical evidence that advice in this area is warranted. This document is a product of the Privacy Enhancements and AssessmentsResearch Group (PEARG) in the IRTF.

RFC 9415 On the Generation of Transient Numeric Identifiers

Authors: F. Gont, I. Arce.

Date: July 2023

Formats: txt html xml json pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9415

This document performs an analysis of the security and privacy implications of different types of "transient numeric identifiers" used in IETF protocols and tries to categorize them based on their interoperability requirements and their associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier category while minimizing the negative security and privacy implications, thus providing guidance to protocol designers and protocol implementers.Finally, it describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers and analyzes their security and privacy properties. This document is a product of the Privacy Enhancements and Assessments Research Group(PEARG) in the IRTF.

RFC 9416 Security Considerations for Transient Numeric Identifiers Employed in Network Protocols

Authors: F. Gont, I. Arce.

Date: July 2023

Formats: txt pdf xml json html

Updates: RFC 3552

Also: BCP 0072

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9416

Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) or data injection to information leakages that can be exploited by pervasive monitoring. Due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed, since these techniques might not mitigate all the associated issues. This document formally updates RFC 3552, incorporating requirements for transient numeric identifiers, to prevent flaws in future protocols and implementations.

RFC 9417 Service Assurance for Intent-Based Networking Architecture

Authors: B. Claise, J. Quilbeuf, D. Lopez, D. Voyer, T. Arumugam.

Date: July 2023

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9417

This document describes an architecture that provides some assurance that service instances are running as expected. As services rely upon multiple subservices provided by a variety of elements, including the underlying network devices and functions, getting the assurance of a healthy service is only possible with a holistic view of all involved elements. This architecture not only helps to correlate the service degradation with symptoms of a specific network component but, it also lists the services impacted by the failure or degradation of a specific network component.

RFC 9418 A YANG Data Model for Service Assurance

Authors: B. Claise, J. Quilbeuf, P. Lucente, P. Fasano, T. Arumugam.

Date: July 2023

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9418

This document specifies YANG modules for representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices.The companion document, "Service Assurance for Intent-BasedNetworking Architecture" (RFC 9417), presents an architecture for implementing the assurance of such services.
The YANG data models in this document conform to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342.

RFC 9419 Considerations on Application - Network Collaboration Using Path Signals

Authors: J. Arkko, T. Hardie, T. Pauly, M. Kühlewind.

Date: July 2023

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9419

This document discusses principles for designing mechanisms that use or provide path signals and calls for standards action in specific valuable cases. RFC 8558 describes path signals as messages to or from on-path elements and points out that visible information will be used whether or not it is intended as a signal. The principles in this document are intended as guidance for the design of explicit path signals, which are encouraged to be authenticated and include a minimal set of parties to minimize information sharing. These principles can be achieved through mechanisms like encryption of information and establishing trust relationships between entities on a path.

RFC 9420 The Messaging Layer Security (MLS) Protocol

Authors: R. Barnes, B. Beurdouche, R. Robert, J. Millican, E. Omara, K. Cohn-Gordon.

Date: July 2023

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9420

Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.

RFC 9421 HTTP Message Signatures

Authors: A. Backman, Ed., J. Richer, Ed., M. Sporny.

Date: February 2024

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9421

This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.

RFC 9422 The LIMITS SMTP Service Extension

Authors: N. Freed, J. Klensin.

Date: February 2024

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9422

This document defines a LIMITS extension for the Simple Mail TransferProtocol (SMTP), including submission, as well as the Local MailTransfer Protocol (LMTP). It also defines an associated limit registry. The extension provides the means for an SMTP, submission, or LMTP server to inform the client of limits the server intends to apply to the protocol during the current session. The client is then able to adapt its behavior in order to conform to those limits.

RFC 9423 Constrained RESTful Environments (CoRE) Target Attributes Registry

Authors: C. Bormann.

Date: April 2024

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9423

The Constrained RESTful Environments (CoRE) specifications apply web technologies to constrained environments. One such important technology is Web Linking (RFC 8288), which CoRE specifications use as the basis for a number of discovery protocols, such as the LinkFormat (RFC 6690) in the Constrained Application Protocol's (CoAP's) resource discovery process (Section 7.2 of RFC 7252) and the ResourceDirectory (RD) (RFC 9176).
Web Links can have target attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of RFC 8288). This document introduces an IANA registry for coordinating names of target attributes when used in CoRE. It updates the "RD Parameters" IANA registry created by RFC 9176 to coordinate with this registry.

RFC 9424 Indicators of Compromise (IoCs) and Their Role in Attack Defence

Authors: K. Paine, O. Whitehouse, J. Sellwood, A. Shaw.

Date: August 2023

Formats: txt pdf html xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9424

Cyber defenders frequently rely on Indicators of Compromise (IoCs) to identify, trace, and block malicious activity in networks or on endpoints. This document reviews the fundamentals, opportunities, operational limitations, and recommendations for IoC use. It highlights the need for IoCs to be detectable in implementations ofInternet protocols, tools, and technologies -- both for the IoCs' initial discovery and their use in detection -- and provides a foundation for approaches to operational challenges in network security.

RFC 9425 JSON Meta Application Protocol (JMAP) for Quotas

Authors: R. Cordier, Ed..

Date: June 2023

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9425

This document specifies a data model for handling quotas on accounts with a server using the JSON Meta Application Protocol (JMAP).

RFC 9426 BATched Sparse (BATS) Coding Scheme for Multi-hop Data Transport

Authors: S. Yang, X. Huang, R. Yeung, J. Zao.

Date: July 2023

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9426

In general, linear network coding can improve the network communication performance in terms of throughput, latency, and reliability. BATched Sparse (BATS) code is a class of efficient linear network coding scheme with a matrix generalization of fountain codes as the outer code and batch-based linear network coding as the inner code. This document describes a baseline BATS coding scheme for communication through multi-hop networks and discusses the related research issues towards a more sophisticated BATS coding scheme. This document is a product of the Coding for EfficientNetwork Communications Research Group (NWCRG).

RFC 9427 TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3

Authors: A. DeKok.

Date: June 2023

Formats: txt json html xml pdf

Updates: RFC 4851, RFC 5281, RFC 7170

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9427

The Extensible Authentication Protocol-TLS (EAP-TLS) (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many other EAP Types also depend on TLS, such as EAP-Flexible Authentication via SecureTunneling (EAP-FAST) (RFC 4851), EAP-Tunneled TLS (EAP-TTLS) (RFC5281), the Tunnel Extensible Authentication Protocol (TEAP) (RFC7170). It is possible that many vendor-specific EAP methods, such as the Protected Extensible Authentication Protocol (PEAP), depend onTLS as well. This document updates those methods in order to use the new key derivation methods available in TLS 1.3. Additional changes necessitated by TLS 1.3 are also discussed.

RFC 9428 Transmission of IPv6 Packets over Near Field Communication

Authors: Y. Choi, Ed., Y-G. Hong, J-S. Youn.

Date: July 2023

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9428

Near Field Communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm apart. NFC standards cover communication protocols and data exchange formats and are based on existing Radio FrequencyIdentification (RFID) standards, including ISO/IEC 14443 and FeliCa.The standards include ISO/IEC 18092 and those defined by the NFCForum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using IPv6 overLow-Power Wireless Personal Area Network (6LoWPAN) techniques.

RFC 9429 JavaScript Session Establishment Protocol (JSEP)

Authors: J. Uberti, C. Jennings, E. Rescorla, Ed..

Date: April 2024

Formats: txt html json xml pdf

Obsoletes: RFC 8829

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9429

This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols.
This specification obsoletes RFC 8829.

RFC 9430 Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS)

Authors: O. Bergmann, J. Preuß Mattsson, G. Selander.

Date: July 2023

Formats: txt html pdf xml json

Updates: RFC 9202

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9430

This document updates "Datagram Transport Layer Security (DTLS)Profile for Authentication and Authorization for ConstrainedEnvironments (ACE)" (RFC 9202) by specifying that the profile applies to TLS as well as DTLS.

RFC 9431 Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework

Authors: C. Sengul, A. Kirby.

Date: July 2023

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9431

This document specifies a profile for the Authentication andAuthorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based onMessage Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication.

RFC 9432 DNS Catalog Zones

Authors: P. van Dijk, L. Peltan, O. Surý, W. Toorop, C.R. Monshouwer, P. Thomassen, A. Sargsyan.

Date: July 2023

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9432

This document describes a method for automatic DNS zone provisioning among DNS primary and secondary name servers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones.

RFC 9433 Segment Routing over IPv6 for the Mobile User Plane

Authors: S. Matsushima, Ed., C. Filsfils, M. Kohno, P. Camarillo, Ed., D. Voyer.

Date: July 2023

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9433

This document discusses the applicability of Segment Routing overIPv6 (SRv6) to the user plane of mobile networks. The network programming nature of SRv6 accomplishes mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user plane, providing flexibility, end-to- end network slicing, and Service Level Agreement (SLA) control for various applications.
This document discusses how SRv6 could be used as the user plane of mobile networks. This document also specifies the SRv6 EndpointBehaviors required for mobility use cases.

RFC 9434 Drone Remote Identification Protocol (DRIP) Architecture

Authors: S. Card, A. Wiethuechter, R. Moskowitz, S. Zhao, Ed., A. Gurtov.

Date: July 2023

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9434

This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking(UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote IdentificationProtocol (DRIP) Requirements document (RFC 9153).

RFC 9435 Considerations for Assigning a New Recommended Differentiated Services Code Point (DSCP)

Authors: A. Custura, G. Fairhurst, R. Secchi.

Date: July 2023

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9435

This document discusses considerations for assigning a new recommended Differentiated Services Code Point (DSCP) for a standardPer-Hop Behavior (PHB). It considers the common observed re-marking behaviors that the Diffserv field might be subjected to along anInternet path. It also notes some implications of using a specificDSCP.

RFC 9436 PIM Message Type Space Extension and Reserved Bits

Authors: S. Venaas, A. Retana.

Date: August 2023

Formats: txt json pdf html xml

Obsoletes: RFC 8736

Updates: RFC 3973, RFC 5015, RFC 5059, RFC 6754, RFC 7761, RFC 8364

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9436

The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and extends the PIM type space.
This document updates RFCs 7761 and 3973 by defining the use of theReserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and8364, by specifying the use of the bits for each PIM message.
This document obsoletes RFC 8736.

RFC 9437 Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP)

Authors: A. Rodriguez-Natal, V. Ermagan, A. Cabellos, S. Barkai, M. Boucadair.

Date: August 2023

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9437

This document specifies an extension to the Locator/ID SeparationProtocol (LISP) control plane to enable Publish/Subscribe (PubSub) operation.

RFC 9438 CUBIC for Fast and Long-Distance Networks

Authors: L. Xu, S. Ha, I. Rhee, V. Goel, L. Eggert, Ed..

Date: August 2023

Formats: txt html json pdf xml

Obsoletes: RFC 8312

Updates: RFC 5681

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9438

CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long- distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
This document updates the specification of CUBIC to include algorithmic improvements based on these implementations and recent academic work. Based on the extensive deployment experience withCUBIC, this document also moves the specification to the StandardsTrack and obsoletes RFC 8312. This document also updates RFC 5681, to allow for CUBIC's occasionally more aggressive sending behavior.

RFC 9439 Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics

Authors: Q. Wu, Y. Yang, Y. Lee, D. Dhody, S. Randriamasy, L. Contreras.

Date: August 2023

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9439

The cost metric is a basic concept in Application-Layer TrafficOptimization (ALTO), and different applications may use different types of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (namely, the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request in order to identify a resource provider that offers better performance metrics (e.g., lower delay or loss rate), the base protocol does not define the cost metric to be used.
This document addresses this issue by extending the specification to provide a variety of network performance metrics, including network delay, delay variation (a.k.a. jitter), packet loss rate, hop count, and bandwidth.
There are multiple sources (e.g., estimations based on measurements or a Service Level Agreement) available for deriving a performance metric. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey the source of a performance metric.

RFC 9440 Client-Cert HTTP Header Field

Authors: B. Campbell, M. Bishop.

Date: July 2023

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9440

This document describes HTTP extension header fields that allow a TLS terminating reverse proxy (TTRP) to convey the client certificate information of a mutually authenticated TLS connection to the origin server in a common and predictable manner.

RFC 9441 Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)

Authors: J. Zúñiga, C. Gomez, S. Aguilar, L. Toutain, S. Céspedes, D. Wistuba.

Date: July 2023

Formats: txt xml pdf json html

Updates: RFC 8724, RFC 9363

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9441

This document updates the Static Context Header Compression (SCHC) and fragmentation protocol (RFC 8724) and the corresponding YANG module (RFC 9363). It defines a SCHC Compound Acknowledgement (ACK) message format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error Mode, by accumulating bitmaps of several windows in a single SCHC message(i.e., the SCHC Compound ACK).
Both the message format and procedure are generic, so they can be used, for instance, by any of the four Low-Power Wide Area Network(LPWAN) technologies defined in RFC 8376, which are Sigfox, LongRange Wide Area Network (LoRaWAN), Narrowband Internet of Things (NB-IoT), and IEEE 802.15.4w.

RFC 9442 Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Network (LPWAN)

Authors: J. Zúñiga, C. Gomez, S. Aguilar, L. Toutain, S. Céspedes, D. Wistuba, J. Boite.

Date: July 2023

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9442

The Static Context Header Compression (SCHC) and fragmentation specification (RFC 8724) describes a generic framework for application header compression and fragmentation modes designed forLow-Power Wide Area Network (LPWAN) technologies. This document defines a profile of SCHC over Sigfox LPWAN and provides optimal parameter values and modes of operation.

RFC 9443 Multiplexing Scheme Updates for QUIC

Authors: B. Aboba, G. Salgueiro, C. Perkins.

Date: July 2023

Formats: txt html json pdf xml

Updates: RFC 5764, RFC 7983

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9443

RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS),Session Traversal Utilities for NAT (STUN), Secure Real-timeTransport Protocol (SRTP) / Secure Real-time Transport ControlProtocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port. This document updates RFC7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket.

RFC 9444 Automated Certificate Management Environment (ACME) for Subdomains

Authors: O. Friel, R. Barnes, T. Hollebeek, M. Richardson.

Date: August 2023

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9444

This document specifies how Automated Certificate ManagementEnvironment (ACME) can be used by a client to obtain a certificate for a subdomain identifier from a certification authority.Additionally, this document specifies how a client can fulfill a challenge against an ancestor domain but may not need to fulfill a challenge against the explicit subdomain if certification authority policy allows issuance of the subdomain certificate without explicit subdomain ownership proof.

RFC 9445 RADIUS Extensions for DHCP-Configured Services

Authors: M. Boucadair, T. Reddy.K, A. DeKok.

Date: August 2023

Formats: txt json pdf html xml

Updates: RFC 4014

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9445

This document specifies two new Remote Authentication Dial-In UserService (RADIUS) attributes that carry DHCP options. The specification is generic and can be applicable to any service that relies upon DHCP. Both DHCPv4- and DHCPv6-configured services are covered.
Also, this document updates RFC 4014 by relaxing a constraint on permitted RADIUS attributes in the RADIUS Attributes DHCP suboption.

RFC 9446 Reflections on Ten Years Past the Snowden Revelations

Authors: S. Farrell, F. Badii, B. Schneier, S. M. Bellovin.

Date: July 2023

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9446

This memo contains the thoughts and recountings of events that transpired during and after the release of information about theUnited States National Security Agency (NSA) by Edward Snowden in2013. There are four perspectives: that of someone who was involved with sifting through the information to responsibly inform the public, that of a security area director of the IETF, that of a human rights expert, and that of a computer science and affiliate law professor. The purpose of this memo is to provide some historical perspective, while at the same time offering a view as to what security and privacy challenges the technical community should consider. These essays do not represent a consensus view, but that of the individual authors.

RFC 9447 Automated Certificate Management Environment (ACME) Challenges Using an Authority Token

Authors: J. Peterson, M. Barnes, D. Hancock, C. Wendt.

Date: September 2023

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9447

Some proposed extensions to the Automated Certificate ManagementEnvironment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a genericAuthority Token Challenge for ACME that supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications.

RFC 9448 TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token

Authors: C. Wendt, D. Hancock, M. Barnes, J. Peterson.

Date: September 2023

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9448

This document defines a profile of the Automated CertificateManagement Environment (ACME) Authority Token for the automated and authorized creation of certificates for Voice over IP (VoIP) telephone providers to support Secure Telephone Identity (STI) using the TNAuthList defined by STI certificates.

RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)

Authors: D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, D. Waite.

Date: September 2023

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9449

This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level.This mechanism allows for the detection of replay attacks with access and refresh tokens.

RFC 9450 Reliable and Available Wireless (RAW) Use Cases

Authors: CJ. Bernardos, Ed., G. Papadopoulos, P. Thubert, F. Theoleyre.

Date: August 2023

Formats: txt json pdf xml html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9450

The wireless medium presents significant specific challenges to achieve properties similar to those of wired deterministic networks.At the same time, a number of use cases cannot be solved with wires and justify the extra effort of going wireless. This document presents wireless use cases (such as aeronautical communications, amusement parks, industrial applications, pro audio and video, gaming, Unmanned Aerial Vehicle (UAV) and vehicle-to-vehicle (V2V) control, edge robotics, and emergency vehicles), demanding reliable and available behavior.

RFC 9451 Operations, Administration, and Maintenance (OAM) Packet and Behavior in the Network Service Header (NSH)

Authors: M. Boucadair.

Date: August 2023

Formats: txt pdf xml json html

Updates: RFC 8300

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9451

This document clarifies an ambiguity in the Network Service Header(NSH) specification related to the handling of O bit. In particular, this document clarifies the meaning of "OAM packet".
This document updates RFC 8300.

RFC 9452 Network Service Header (NSH) Encapsulation for In Situ OAM (IOAM) Data

Authors: F. Brockners, Ed., S. Bhandari, Ed..

Date: August 2023

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9452

In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network.This document outlines how IOAM-Data-Fields are encapsulated with theNetwork Service Header (NSH).

RFC 9453 Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo)

Authors: Y. Hong, C. Gomez, Y. Choi, A. Sangi, S. Chakrabarti.

Date: September 2023

Formats: txt html json xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9453

This document describes the applicability of IPv6 over constrained- node networks (6lo) and provides practical deployment examples. In addition to IEEE Std 802.15.4, various link-layer technologies are used as examples, such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy(Bluetooth LE), Digital Enhanced Cordless Telecommunications - UltraLow Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near FieldCommunication (NFC), and Power Line Communication (PLC). This document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained-node networks for local or Internet connectivity.

RFC 9454 Update to OSPF Terminology

Authors: M. Fox, A. Lindem, A. Retana.

Date: August 2023

Formats: txt json xml pdf html

Updates: RFC 2328, RFC 4222, RFC 4811, RFC 5243, RFC 5340, RFC 5614, RFC 5838

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9454

This document updates some OSPF terminology to be in line with inclusive language used in the industry. The IETF has designated"Guidance for NIST Staff on Using Inclusive Language in DocumentaryStandards" by the US National Institute of Standards and Technology(NIST) for its inclusive language guidelines. It is intended that all future OSPF documents use this revised terminology even when they reference the RFCs updated by this document.
This document updates RFCs 2328, 4222, 4811, 5243, 5340, 5614, and5838.

RFC 9455 Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes

Authors: Z. Yan, R. Bush, G. Geng, T. de Kock, J. Yao.

Date: August 2023

Formats: txt json html xml pdf

Also: BCP 0238

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9455

When using the Resource Public Key Infrastructure (RPKI), address space holders need to issue Route Origin Authorization (ROA) object(s) to authorize one or more Autonomous Systems (ASes) to originate BGP routes to IP address prefix(es). This memo discusses operational problems that may arise from ROAs containing multiple IP prefixes and recommends that each ROA contain a single IP prefix.

RFC 9456 Updates to the TLS Transport Model for SNMP

Authors: K. Vaughn, Ed..

Date: November 2023

Formats: txt pdf xml html json

Updates: RFC 6353

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9456

This document updates RFC 6353 ("Transport Layer Security (TLS)Transport Model for the Simple Network Management Protocol (SNMP)") to reflect changes necessary to support Transport Layer Security version 1.3 (TLS 1.3) and Datagram Transport Layer Security version1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3". This document is compatible with (D)TLS 1.2 and is intended to be compatible with future versions of SNMP and (D)TLS.
This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.

RFC 9457 Problem Details for HTTP APIs

Authors: M. Nottingham, E. Wilde, S. Dalal.

Date: July 2023

Formats: txt html pdf xml json

Obsoletes: RFC 7807

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9457

This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.
This document obsoletes RFC 7807.

RFC 9458 Oblivious HTTP

Authors: M. Thomson, C. A. Wood.

Date: January 2024

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9458

This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages.

RFC 9459 CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC

Authors: R. Housley, H. Tschofenig.

Date: September 2023

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9459

The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size. CBOR ObjectSigning and Encryption (COSE) is specified in RFC 9052 to provide basic security services using the CBOR data format. This document specifies the conventions for using AES-CTR and AES-CBC as content encryption algorithms with COSE.

RFC 9460 Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)

Authors: B. Schwartz, M. Bishop, E. Nygren.

Date: November 2023

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9460

This document specifies the "SVCB" ("Service Binding") and "HTTPS"DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible withCNAME. The HTTPS RR is a variation of SVCB for use with HTTP (seeRFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.

RFC 9461 Service Binding Mapping for DNS Servers

Authors: B. Schwartz.

Date: November 2023

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9461

The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols.

RFC 9462 Discovery of Designated Resolvers

Authors: T. Pauly, E. Kinnear, C. A. Wood, P. McManus, T. Jensen.

Date: November 2023

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9462

This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver".These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNSResolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNSResolver is known.

RFC 9463 DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

Authors: M. Boucadair, Ed., T. Reddy.K, Ed., D. Wing, N. Cook, T. Jensen.

Date: November 2023

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9463

This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS,DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers.

RFC 9464 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS

Authors: M. Boucadair, T. Reddy.K, D. Wing, V. Smyslov.

Date: November 2023

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9464

This document specifies new Internet Key Exchange Protocol Version 2(IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS over HTTPS (DoH),DNS over TLS (DoT), and DNS over QUIC (DoQ).

RFC 9465 PIM Null-Register Packing

Authors: V. Kamath, R. Chokkanathapuram Sundaram, R. Banthia, A. Gopal.

Date: September 2023

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9465

In PIM Sparse Mode (PIM-SM) networks, PIM Null-Register messages are sent by the Designated Router (DR) to the Rendezvous Point (RP) to signal the presence of multicast sources in the network. There are periodic PIM Null-Registers sent from the DR to the RP to keep the state alive at the RP as long as the source is active. The PIM Null-Register message carries information about a single multicast source and group.
This document defines a standard to send information about multiple multicast sources and groups in a single PIM message. This document refers to the new messages as the "PIM Packed Null-Register message" and "PIM Packed Register-Stop message".

RFC 9466 PIM Assert Message Packing

Authors: Y. Liu, Ed., T. Eckert, Ed., M. McBride, Z. Zhang.

Date: October 2023

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9466

When PIM Sparse Mode (PIM-SM), including PIM Source-SpecificMulticast (PIM-SSM), is used in shared LAN networks, there is often more than one upstream router. This can lead to duplicate IP multicast packets being forwarded by these PIM routers. PIM Assert messages are used to elect a single forwarder for each IP multicast traffic flow between these routers.
This document defines a mechanism to send and receive information for multiple IP multicast flows in a single PackedAssert message. This optimization reduces the total number of PIM packets on the LAN and can therefore speed up the election of the single forwarder, reducing the number of duplicate IP multicast packets incurred.

RFC 9467 Relaxed Packet Counter Verification for Babel MAC Authentication

Authors: J. Chroboczek, T. Høiland-Jørgensen.

Date: January 2024

Formats: txt html xml pdf json

Updates: RFC 8967

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9467

This document relaxes the packet verification rules defined in "MACAuthentication for the Babel Routing Protocol" (RFC 8967) in order to make the protocol more robust in the presence of packet reordering.This document updates RFC 8967.

RFC 9468 Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications

Authors: E. Chen, N. Shen, R. Raszuk, R. Rahman.

Date: August 2023

Formats: txt json xml pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9468

For operational simplification of "sessionless" applications usingBidirectional Forwarding Detection (BFD), in this document, we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side and established without explicit per- session configuration or registration by the other side (subject to certain per-interface or global policies).
We also introduce a new YANG module to configure and manage"unsolicited BFD". The YANG module in this document is based on YANG1.1, as defined in RFC 7950, and conforms to the Network ManagementDatastore Architecture (NMDA), as described in RFC 8342. This document augments RFC 9314.

RFC 9469 Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks

Authors: J. Rabadan, Ed., M. Bocci, S. Boutros, A. Sajassi.

Date: September 2023

Formats: txt json xml html pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9469

An Ethernet Virtual Private Network (EVPN) provides a unified control plane that solves the issues of Network Virtualization Edge (NVE) auto-discovery, tenant Media Access Control (MAC) / IP dissemination, and advanced features in a scablable way as required by NetworkVirtualization over Layer 3 (NVO3) networks. EVPN is a scalable solution for NVO3 networks and keeps the independence of the underlayIP Fabric, i.e., there is no need to enable Protocol IndependentMulticast (PIM) in the underlay network and maintain multicast states for tenant Broadcast Domains. This document describes the use ofEVPN for NVO3 networks and discusses its applicability to basic Layer2 and Layer 3 connectivity requirements and to advanced features such as MAC Mobility, MAC Protection and Loop Protection, multihoming,Data Center Interconnect (DCI), and much more. No new EVPN procedures are introduced.

RFC 9470 OAuth 2.0 Step Up Authentication Challenge Protocol

Authors: V. Bertocci, B. Campbell.

Date: September 2023

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9470

It is not uncommon for resource servers to require different authentication strengths or recentness according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and, further, how to meet them. This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request.

RFC 9471 DNS Glue Requirements in Referral Responses

Authors: M. Andrews, S. Huque, P. Wouters, D. Wessels.

Date: September 2023

Formats: txt json pdf html xml

Updates: RFC 1034

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9471

The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone.Authoritative servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior.

RFC 9472 A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information

Authors: E. Lear, S. Rose.

Date: October 2023

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9472

To improve cybersecurity posture, automation is necessary to locate the software a device is using, whether that software has known vulnerabilities, and what, if any, recommendations suppliers may have. This memo extends the Manufacturer User Description (MUD) YANG schema to provide the locations of software bills of materials(SBOMs) and vulnerability information by introducing a transparency schema.

RFC 9473 A Vocabulary of Path Properties

Authors: R. Enghardt, C. Krähenbühl.

Date: September 2023

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9473

Path properties express information about paths across a network and the services provided via such paths. In a path-aware network, path properties may be fully or partially available to entities such as endpoints. This document defines and categorizes path properties.Furthermore, the document identifies several path properties that might be useful to endpoints or other entities, e.g., for selecting between paths or for invoking some of the provided services. This document is a product of the Path Aware Networking Research Group(PANRG).

RFC 9474 RSA Blind Signatures

Authors: F. Denis, F. Jacobs, C. A. Wood.

Date: October 2023

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9474

This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments. A signature that is output from this protocol can be verified as an RSA-PSS signature.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

RFC 9475 Messaging Use Cases and Extensions for Secure Telephone Identity Revisited (STIR)

Authors: J. Peterson, C. Wendt.

Date: December 2023

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9475

Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller via a signed token in order to prevent impersonation of a calling party number, which is a key enabler for illegal robocalling. Similar impersonation is sometimes leveraged by bad actors in the text and multimedia messaging space. This document explores the applicability of STIR'sPersonal Assertion Token (PASSporT) and certificate issuance framework to text and multimedia messaging use cases, including support for both messages carried as a payload in SIP requests and messages sent in sessions negotiated by SIP.

RFC 9476 The .alt Special-Use Top-Level Domain

Authors: W. Kumari, P. Hoffman.

Date: September 2023

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9476

This document reserves a Top-Level Domain (TLD) label "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers creating alternative namespaces.

RFC 9477 Complaint Feedback Loop Address Header

Authors: J. Benecke.

Date: September 2023

Formats: txt html pdf xml json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9477

This document describes a method that allows a Message Originator to specify a Complaint Feedback Loop (CFBL) address as a message header field. It also defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automated way to provide Mailbox Providers with an address for a CFBL. Currently, providing and maintaining such an address is a manual and time-consuming process for MessageOriginators and Mailbox Providers.
The mechanism specified in this document is being published as an experiment to gather feedback and gauge the interest of implementers and deployers. This document is produced through the Independent RFCStream and was not subject to the IETF's approval process.

RFC 9478 Labeled IPsec Traffic Selector Support for the Internet Key Exchange Protocol Version 2 (IKEv2)

Authors: P. Wouters, S. Prasad.

Date: October 2023

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9478

This document defines a new Traffic Selector Type (TS Type) for theInternet Key Exchange Protocol version 2 (IKEv2) to add support for negotiating Mandatory Access Control (MAC) security labels as aTraffic Selector of the Security Policy Database (SPD). SecurityLabels for IPsec are also known as "Labeled IPsec". The new TS Type,TS_SECLABEL, consists of a variable length opaque field that specifies the security label.

RFC 9479 IS-IS Application-Specific Link Attributes

Authors: L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake.

Date: October 2023

Formats: txt json pdf xml html

Obsoletes: RFC 8919

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9479

Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support an indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements that address both of these shortcomings.
This document obsoletes RFC 8919.

RFC 9480 Certificate Management Protocol (CMP) Updates

Authors: H. Brockhaus, D. von Oheimb, J. Gray.

Date: November 2023

Formats: txt json pdf xml html

Updates: RFC 4210, RFC 5912, RFC 6712

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9480

This document contains a set of updates to the syntax of CertificateManagement Protocol (CMP) version 2 and its HTTP transfer mechanism.This document updates RFCs 4210, 5912, and 6712.
The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments.
CMP version 3 is introduced to enable signaling support ofEnvelopedData instead of EncryptedValue and signal the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed.

RFC 9481 Certificate Management Protocol (CMP) Algorithms

Authors: H. Brockhaus, H. Aschauer, M. Ounsworth, J. Gray.

Date: November 2023

Formats: txt pdf json xml html

Updates: RFC 4210

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9481

This document describes the conventions for using several cryptographic algorithms with the Certificate Management Protocol(CMP). CMP is used to enroll and further manage the lifecycle ofX.509 certificates. This document also updates the algorithm use profile from Appendix D.2 of RFC 4210.

RFC 9482 Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol

Authors: M. Sahni, Ed., S. Tripathi, Ed..

Date: November 2023

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9482

This document specifies the use of the Constrained ApplicationProtocol (CoAP) as a transfer mechanism for the CertificateManagement Protocol (CMP). CMP defines the interaction between various PKI entities for the purpose of certificate creation and management. CoAP is an HTTP-like client-server protocol used by various constrained devices in the Internet of Things space.

RFC 9483 Lightweight Certificate Management Protocol (CMP) Profile

Authors: H. Brockhaus, D. von Oheimb, S. Fries.

Date: November 2023

Formats: txt html json xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9483

This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial andInternet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related CertificateRequest Message Format (CRMF), and transfer based on HTTP orConstrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features.

RFC 9484 Proxying IP in HTTP

Authors: T. Pauly, Ed., D. Schinazi, A. Chernyakhovsky, M. Kühlewind, M. Westerlund.

Date: October 2023

Formats: txt json xml html pdf

Updates: RFC 9298

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9484

This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through anHTTP server that acts as an IP proxy. This document updates RFC9298.

RFC 9485 I-Regexp: An Interoperable Regular Expression Format

Authors: C. Bormann, T. Bray.

Date: October 2023

Formats: txt json xml html pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9485

This document specifies I-Regexp, a flavor of regular expression that is limited in scope with the goal of interoperation across many different regular expression libraries.

RFC 9486 IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)

Authors: S. Bhandari, Ed., F. Brockners, Ed..

Date: September 2023

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9486

In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM Data-Fields are encapsulated in IPv6.

RFC 9487 Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)

Authors: T. Graf, B. Claise, P. Francois.

Date: November 2023

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9487

This document introduces new IP Flow Information Export (IPFIX)Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in aSegment Routing Header (SRH), the SRv6 control plane, and the SRv6Endpoint behavior that traffic is being forwarded with.

RFC 9488 Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP)

Authors: A. Stone, M. Aissaoui, S. Sidor, S. Sivabalan.

Date: October 2023

Formats: txt json pdf xml html

Updates: RFC 5440

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9488

This document updates RFC 5440 to clarify usage of the LocalProtection Desired bit signaled in the Path Computation ElementCommunication Protocol (PCEP). This document also introduces a new flag for signaling protection enforcement in PCEP.

RFC 9489 Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN)

Authors: P. Jain, A. Sajassi, S. Salam, S. Boutros, G. Mirsky.

Date: November 2023

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9489

Label Switched Path (LSP) Ping is a widely deployed Operations,Administration, and Maintenance (OAM) mechanism in MPLS networks.This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS-based Ethernet VPN (EVPN) and ProviderBackbone Bridging EVPN (PBB-EVPN) networks.

RFC 9490 Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)

Authors: M. Knodel, W. Hardaker, T. Pauly.

Date: January 2024

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9490

The "Management Techniques in Encrypted Networks (M-TEN)" workshop was convened by the Internet Architecture Board (IAB) from 17 October2022 to 19 October 2022 as a three-day online meeting. The workshop was organized in three parts to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the expressed during the workshop by participants and do not necessarily reflect IAB views and positions.

RFC 9491 Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)

Authors: J. Guichard, Ed., J. Tantsura, Ed..

Date: November 2023

Formats: txt xml pdf json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9491

This document describes the integration of the Network Service Header(NSH) and Segment Routing (SR), as well as encapsulation details, to efficiently support Service Function Chaining (SFC) while maintaining separation of the service and transport planes as originally intended by the SFC architecture.
Combining these technologies allows SR to be used for steering packets between Service Function Forwarders (SFFs) along a givenService Function Path (SFP), whereas the NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata.
This integration demonstrates that the NSH and SR can work cooperatively and provide a network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure while still maintaining an end-to-end service plane using the NSH.

RFC 9492 OSPF Application-Specific Link Attributes

Authors: P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake.

Date: October 2023

Formats: txt html pdf json xml

Obsoletes: RFC 8920

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9492

Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications such as Segment Routing (SR) Policy and Loop-Free Alternates (LFAs) that also make use of the link attribute advertisements have been defined.In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements inOSPFv2 and OSPFv3 that address both of these shortcomings.
This document obsoletes RFC 8920.

RFC 9493 Subject Identifiers for Security Event Tokens

Authors: A. Backman, Ed., M. Scurtescu, P. Jain.

Date: December 2023

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9493

Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event.This specification formalizes the notion of Subject Identifiers as structured information that describes a subject and named formats that define the syntax and semantics for encoding Subject Identifiers as JSON objects. It also establishes a registry for defining and allocating names for such formats as well as the JSON Web Token (JWT)"sub_id" Claim.

RFC 9494 Long-Lived Graceful Restart for BGP

Authors: J. Uttaro, E. Chen, B. Decraene, J. Scudder.

Date: November 2023

Formats: txt json pdf xml html

Updates: RFC 6368

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9494

This document introduces a BGP capability called the "Long-LivedGraceful Restart Capability" (or "LLGR Capability"). The benefit of this capability is that stale routes can be retained for a longer time upon session failure than is provided for by BGP GracefulRestart (as described in RFC 4724). A well-known BGP community called "LLGR_STALE" is introduced for marking stale routes retained for a longer time. A second well-known BGP community called"NO_LLGR" is introduced for marking routes for which these procedures should not be applied. We also specify that such long-lived stale routes be treated as the least preferred and that their advertisements be limited to BGP speakers that have advertised the capability. Use of this extension is not advisable in all cases, and we provide guidelines to help determine if it is.
This memo updates RFC 6368 by specifying that the LLGR_STALE community must be propagated into, or out of, the path attributes exchanged between the Provider Edge (PE) and Customer Edge (CE) routers.

RFC 9495 Certification Authority Authorization (CAA) Processing for Email Addresses

Authors: C. Bonnell.

Date: October 2023

Formats: txt json html pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9495

The Certification Authority Authorization (CAA) DNS resource record(RR) provides a mechanism for domains to express the allowed set ofCertification Authorities that are authorized to issue certificates for the domain. RFC 8659 contains the core CAA specification, whereProperty Tags that restrict the issuance of certificates that certify domain names are defined. This specification defines a Property Tag that grants authorization to Certification Authorities to issue certificates that contain the id-kp-emailProtection key purpose in the extendedKeyUsage extension and at least one rfc822Name value or otherName value of type id-on-SmtpUTF8Mailbox that includes the domain name in the subjectAltName extension.

RFC 9496 The ristretto255 and decaf448 Groups

Authors: H. de Valence, J. Grigg, M. Hamburg, I. Lovecruft, G. Tankersley, F. Valsorda.

Date: December 2023

Formats: txt xml html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9496

This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

RFC 9497 Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups

Authors: A. Davidson, A. Faz-Hernandez, N. Sullivan, C. A. Wood.

Date: December 2023

Formats: txt xml html pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9497

An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of aPseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially oblivious, called aPOPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, andPOPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto ForumResearch Group (CFRG) in the IRTF.

RFC 9498 The GNU Name System

Authors: M. Schanzenbach, C. Grothoff, B. Fix.

Date: November 2023

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9498

This document provides the GNU Name System (GNS) technical specification. GNS is a decentralized and censorship-resistant domain name resolution protocol that provides a privacy-enhancing alternative to the Domain Name System (DNS) protocols.
This document defines the normative wire format of resource records, resolution processes, cryptographic routines, and security and privacy considerations for use by implementers.
This specification was developed outside the IETF and does not haveIETF consensus. It is published here to inform readers about the function of GNS, guide future GNS implementations, and ensure interoperability among implementations (for example, pre-existingGNUnet implementations).

RFC 9499 DNS Terminology

Authors: P. Hoffman, K. Fujiwara.

Date: March 2024

Formats: txt xml pdf json html

Obsoletes: RFC 8499

Updates: RFC 2308

Also: BCP 0219

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9499

The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.
This document updates RFC 2308 by clarifying the definitions of"forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.

RFC 9500 Standard Public Key Cryptography (PKC) Test Keys

Authors: P. Gutmann, C. Bonnell.

Date: December 2023

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9500

This document provides a set of standard Public Key Cryptography(PKC) test keys that may be used wherever pre-generated keys and associated operations like digital signatures are required. Like theEuropean Institute for Computer Antivirus Research (EICAR) virus test and the Generic Test for Unsolicited Bulk Email (GTUBE) spam test files, these publicly known test keys can be detected and recognised by applications consuming them as being purely for testing purposes without assigning any security properties to them.

RFC 9501 Open Participation Principle regarding Remote Registration Fee

Authors: M. Kühlewind, J. Reed, R. Salz.

Date: December 2023

Formats: txt json pdf xml html

Also: BCP 0239

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9501

This document outlines a principle for open participation that extends the open process principle defined in RFC 3935 by stating that there must be a free option for online participation to IETF meetings and, if possible, related IETF-hosted events.

RFC 9502 IGP Flexible Algorithm in IP Networks

Authors: W. Britto, S. Hegde, P. Kaneriya, R. Shetty, R. Bonica, P. Psenak.

Date: November 2023

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9502

This document extends IGP Flexible Algorithm so that it can be used with regular IPv4 and IPv6 forwarding.

RFC 9503 Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks

Authors: R. Gandhi, Ed., C. Filsfils, M. Chen, B. Janssens, R. Foote.

Date: October 2023

Formats: txt html xml pdf json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9503

Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6(SRv6) forwarding planes. This document specifies Simple Two-WayActive Measurement Protocol (STAMP) extensions (as described in RFC8762) for SR networks, for both the SR-MPLS and SRv6 forwarding planes, by augmenting the optional extensions defined in RFC 8972.

RFC 9504 Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks

Authors: Y. Lee, H. Zheng, O. Gonzalez de Dios, V. Lopez, Z. Ali.

Date: December 2023

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9504

The Path Computation Element Communication Protocol (PCEP) has been extended to support stateful PCE functions where the stateful PCE maintains information about paths and resource usage within a network; however, these extensions do not cover all requirements forGMPLS networks.
This document provides the extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks.

RFC 9505 A Survey of Worldwide Censorship Techniques

Authors: J. L. Hall, M. D. Aaron, A. Andersdotter, B. Jones, N. Feamster, M. Knodel.

Date: November 2023

Formats: txt json xml pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9505

This document describes technical mechanisms employed in network censorship that regimes around the world use for blocking or impairing Internet traffic. It aims to make designers, implementers, and users of Internet protocols aware of the properties exploited and mechanisms used for censoring end-user access to information. This document makes no suggestions on individual protocol considerations, and is purely informational, intended as a reference. This document is a product of the Privacy Enhancement and Assessment Research Group(PEARG) in the IRTF.

RFC 9506 Explicit Host-to-Network Flow Measurements Techniques

Authors: M. Cociglio, A. Ferrieux, G. Fioccola, I. Lubashev, F. Bulgarella, M. Nilo, I. Hamchaoui, R. Sisto.

Date: October 2023

Formats: txt html pdf xml json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9506

This document describes protocol-independent methods called ExplicitHost-to-Network Flow Measurement Techniques that can be applicable to transport-layer protocols between the client and server. These methods employ just a few marking bits inside the header of each packet for performance measurements and require the client and server to collaborate. Both endpoints cooperate by marking packets and, possibly, mirroring the markings on the round-trip connection. The techniques are especially valuable when applied to protocols that encrypt transport headers since they enable loss and delay measurements by passive, on-path network devices. This document describes several methods that can be used separately or jointly depending of the availability of marking bits, desired measurements, and properties of the protocol to which the methods are applied.

RFC 9507 Information-Centric Networking (ICN) Traceroute Protocol Specification

Authors: S. Mastorakis, D. Oran, I. Moiseenko, J. Gibson, R. Droms.

Date: March 2024

Formats: txt pdf xml html json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9507

This document presents the design of an Information-CentricNetworking (ICN) Traceroute protocol. This includes the operation of both the client and the forwarder.
This document is a product of the Information-Centric NetworkingResearch Group (ICNRG) of the IRTF.

RFC 9508 Information-Centric Networking (ICN) Ping Protocol Specification

Authors: S. Mastorakis, D. Oran, J. Gibson, I. Moiseenko, R. Droms.

Date: March 2024

Formats: txt pdf json xml html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9508

This document presents the design of an Information-CentricNetworking (ICN) Ping protocol. It includes the operations of both the client and the forwarder.
This document is a product of the Information-Centric NetworkingResearch Group (ICNRG) of the IRTF.

RFC 9509 X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions

Authors: T. Reddy.K, J. Ekman, D. Migault.

Date: March 2024

Formats: txt pdf json xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9509

RFC 5280 specifies several extended key purpose identifiers(KeyPurposeIds) for X.509 certificates. This document defines encrypting JSON objects in HTTP messages, using JSON Web Tokens(JWTs), and signing the OAuth 2.0 access tokens KeyPurposeIds for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates used by Network Functions (NFs) for the 5GSystem.

RFC 9510 Alternative Delta Time Encoding for Content-Centric Networking (CCNx) Using Compact Floating-Point Arithmetic

Authors: C. Gündoğan, T. Schmidt, D. Oran, M. Wählisch.

Date: February 2024

Formats: txt xml pdf json html

Updates: RFC 8609

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9510

Content-Centric Networking (CCNx) utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes or bandwidth-constrained networks, it is valuable to have a compressed representation of delta time. In order to do so, either accuracy or dynamic range has to be sacrificed. Since the current uses of delta time do not require both simultaneously, one can consider a logarithmic encoding. This document updates RFC 8609 ("CCNx messages in TLV Format") to specify this alternative encoding.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG).

RFC 9511 Attribution of Internet Probes

Authors: É. Vyncke, B. Donnet, J. Iurman.

Date: November 2023

Formats: txt xml json pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9511

Active measurements over the public Internet can target either collaborating parties or non-collaborating ones. Sometimes these measurements, also called "probes", are viewed as unwelcome or aggressive.
This document suggests some simple techniques for a source to identify its probes. This allows any party or organization to understand what an unsolicited probe packet is, what its purpose is, and, most importantly, who to contact. The technique relies on offline analysis of the probe; therefore, it does not require any change in the data or control plane. It has been designed mainly for layer 3 measurements.

RFC 9512 YAML Media Type

Authors: R. Polli, E. Wilde, E. Aro.

Date: February 2024

Formats: txt html json pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9512

This document registers the application/yaml media type and the +yaml structured syntax suffix with IANA. Both identify document components that are serialized according to the YAML specification.

RFC 9513 OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)

Authors: Z. Li, Z. Hu, K. Talaulikar, Ed., P. Psenak.

Date: December 2023

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9513

The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane.

RFC 9514 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)

Authors: G. Dawra, C. Filsfils, K. Talaulikar, Ed., M. Chen, D. Bernier, B. Decraene.

Date: December 2023

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9514

Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments".These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3.
This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085.

RFC 9515 Revision to Registration Procedures for Multiple BMP Registries

Authors: J. Scudder.

Date: December 2023

Formats: txt json html pdf xml

Updates: RFC 7854

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9515

This document updates RFC 7854, "BGP Monitoring Protocol (BMP)", by changing the registration procedures for several registries.Specifically, any BMP registry with a range of 32768-65530 designated"Specification Required" has that range redesignated as "First ComeFirst Served".

RFC 9516 Active Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC)

Authors: G. Mirsky, W. Meng, T. Ao, B. Khasnabish, K. Leung, G. Mishra.

Date: November 2023

Formats: txt xml pdf html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9516

A set of requirements for active Operations, Administration, andMaintenance (OAM) for Service Function Chaining (SFC) in a network is presented in this document. Based on these requirements, an encapsulation of active OAM messages in SFC and a mechanism to detect and localize defects are described.

RFC 9517 A URN Namespace for the Data Documentation Initiative (DDI)

Authors: J. Wackerow.

Date: January 2024

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9517

This document describes the Namespace Identifier (NID) "ddi" forUniform Resource Names (URNs) used to identify resources that conform to the standards published by the Data Documentation Initiative (DDI)Alliance.
The DDI Alliance is not affiliated with the Internet Engineering TaskForce (IETF) or Internet Society (ISOC). This Independent Submission is not a standard nor does it have IETF community consensus.

RFC 9518 Centralization, Decentralization, and Internet Standards

Authors: M. Nottingham.

Date: December 2023

Formats: txt xml pdf json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9518

This document discusses aspects of centralization that relate toInternet standards efforts. It argues that, while standards bodies have a limited ability to prevent many forms of centralization, they can still make contributions that assist in the decentralization of the Internet.

RFC 9519 Update to the IANA SSH Protocol Parameters Registry Requirements

Authors: P. Yee.

Date: January 2024

Formats: txt json xml pdf html

Updates: RFC 4250, RFC 4716, RFC 4819, RFC 8308

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9519

This specification updates the registration policies for adding new entries to registries within the IANA "Secure Shell (SSH) ProtocolParameters" group of registries. Previously, the registration policy was generally IETF Review, as defined in RFC 8126, although a few registries require Standards Action. This specification changes it from IETF Review to Expert Review. This document updates RFCs 4250,4716, 4819, and 8308.

RFC 9520 Negative Caching of DNS Resolution Failures

Authors: D. Wessels, W. Carroll, M. Thomas.

Date: December 2023

Formats: txt json html pdf xml

Updates: RFC 2308, RFC 4035, RFC 4697

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9520

In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data, (2) a response indicating the requested data does not exist, or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type.
RFC 2308 specifies requirements for DNS negative caching. There, caching of TYPE 2 responses is mandatory and caching of TYPE 3 responses is optional. This document updates RFC 2308 to require negative caching for DNS resolution failures.
RFC 4035 allows DNSSEC validation failure caching. This document updates RFC 4035 to require caching for DNSSEC validation failures.
RFC 4697 prohibits aggressive requerying for NS records at a failed zone's parent zone. This document updates RFC 4697 to expand this requirement to all query types and to all ancestor zones.

RFC 9521 Bidirectional Forwarding Detection (BFD) for Generic Network Virtualization Encapsulation (Geneve)

Authors: X. Min, G. Mirsky, S. Pallagatti, J. Tantsura, S. Aldrin.

Date: January 2024

Formats: txt json pdf html xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9521

This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol in point-to-point Generic NetworkVirtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network.

RFC 9522 Overview and Principles of Internet Traffic Engineering

Authors: A. Farrel, Ed..

Date: January 2024

Formats: txt html xml pdf json

Obsoletes: RFC 3272

Status: INFORMATIONAL

DOI: 10.17487/RFC 9522

This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking 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 networks are also discussed.
This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF.

RFC 9523 A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos

Authors: N. Rozen-Schiff, D. Dolev, T. Mizrahi, M. Schapira.

Date: February 2024

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9523

The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is the mechanism used by NTP clients to synchronize with NTP servers across the Internet. This document describes a companion application to the NTPv4 client, named "Khronos", that is used as a "watchdog" alongside NTPv4 and that provides improved security against time- shifting attacks. Khronos involves changes to the NTP client's system process only. Since it does not affect the wire protocol, theKhronos mechanism is applicable to current and future time protocols.

RFC 9524 Segment Routing Replication for Multipoint Service Delivery

Authors: D. Voyer, Ed., C. Filsfils, R. Parekh, H. Bidgoli, Z. Zhang.

Date: February 2024

Formats: txt xml json pdf html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9524

This document describes the Segment Routing Replication segment for multipoint service delivery. A Replication segment allows a packet to be replicated from a replication node to downstream nodes.

RFC 9525 Service Identity in TLS

Authors: P. Saint-Andre, R. Salz.

Date: November 2023

Formats: txt xml json pdf html

Obsoletes: RFC 6125

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9525

Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with InternetPublic Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions.
This document obsoletes RFC 6125.

RFC 9526 Simple Provisioning of Public Names for Residential Networks

Authors: D. Migault, R. Weber, M. Richardson, R. Hunter.

Date: January 2024

Formats: txt html pdf xml json

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9526

Home network owners may have devices or services hosted on their home network that they wish to access from the Internet (i.e., from a network outside of the home network). Home networks are increasingly numbered using IPv6 addresses, which in principle makes this access simpler, but accessing home networks from the Internet requires the names and IP addresses of these devices and services to be made available in the public DNS.
This document describes how a Home Naming Authority (NHA) instructs the outsourced infrastructure to publish these pieces of information in the public DNS. The names and IP addresses of the home network are set in the Public Homenet Zone by the Homenet Naming Authority(HNA), which in turn instructs an outsourced infrastructure to publish the zone on behalf of the home network owner.

RFC 9527 DHCPv6 Options for the Homenet Naming Authority

Authors: D. Migault, R. Weber, T. Mrugalski.

Date: January 2024

Formats: txt html json pdf xml

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9527

This document defines DHCPv6 options so that a Homenet NamingAuthority (HNA) can automatically set the appropriate configuration and outsource the authoritative naming service for the home network.In most cases, the outsourcing mechanism is transparent for the end user.

RFC 9528 Ephemeral Diffie-Hellman Over COSE (EDHOC)

Authors: G. Selander, J. Preuß Mattsson, F. Palombini.

Date: March 2024

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9528

This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption(COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low.

RFC 9529 Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC)

Authors: G. Selander, J. Preuß Mattsson, M. Serafin, M. Tiloca, M. Vučinić.

Date: March 2024

Formats: txt json html pdf xml

Status: INFORMATIONAL

DOI: 10.17487/RFC 9529

This document contains example traces of Ephemeral Diffie-HellmanOver COSE (EDHOC).

RFC 9530 Digest Fields

Authors: R. Polli, L. Pardue.

Date: February 2024

Formats: txt json xml pdf html

Obsoletes: RFC 3230

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9530

This document defines HTTP fields that support integrity digests.The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields.
This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields.

RFC 9531 Path Steering in Content-Centric Networking (CCNx) and Named Data Networking (NDN)

Authors: I. Moiseenko, D. Oran.

Date: March 2024

Formats: txt json html xml pdf

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9531

Path steering is a mechanism to discover paths to the producers ofInformation-Centric Networking (ICN) Content Objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multi- path congestion control algorithms and for network measurement and management. This specification derives directly from the design published in "Path Switching in Content Centric and Named DataNetworks" (4th ACM Conference on Information-Centric Networking) and, therefore, does not recapitulate the design motivations, implementation details, or evaluation of the scheme. However, some technical details are different, and where there are differences, the design documented here is to be considered definitive.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). It is not an IETF product and is not anInternet Standard.

RFC 9532 HTTP Proxy-Status Parameter for Next-Hop Aliases

Authors: T. Pauly.

Date: January 2024

Formats: txt pdf html xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9532

This document defines the next-hop-aliases HTTP Proxy-StatusParameter. This parameter carries the list of aliases and canonical names an intermediary received during DNS resolution as part of establishing a connection to the next hop.

RFC 9533 One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Authors: Z. Li, T. Zhou, J. Guo, G. Mirsky, R. Gandhi.

Date: January 2024

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9533

This document defines extensions to the One-Way Active MeasurementProtocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a LinkAggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance-based traffic steering policy across the member links.

RFC 9534 Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group

Authors: Z. Li, T. Zhou, J. Guo, G. Mirsky, R. Gandhi.

Date: January 2024

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9534

This document extends Simple Two-way Active Measurement Protocol(STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce a performance-based traffic steering policy across the member links.

RFC 9535 JSONPath: Query Expressions for JSON

Authors: S. Gössner, Ed., G. Normington, Ed., C. Bormann, Ed..

Date: February 2024

Formats: txt pdf xml json html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9535

JSONPath defines a string syntax for selecting and extracting JSON(RFC 8259) values from within a given JSON value.

RFC 9536 Registration Data Access Protocol (RDAP) Reverse Search

Authors: M. Loffredo, M. Martinelli.

Date: April 2024

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9536

The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case.

RFC 9537 Redacted Fields in the Registration Data Access Protocol (RDAP) Response

Authors: J. Gould, D. Smith, J. Kolker, R. Carney.

Date: March 2024

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9537

This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language.

RFC 9538 Content Delivery Network Interconnection (CDNI) Delegation Using the Automated Certificate Management Environment

Authors: F. Fieau, Ed., E. Stephan, S. Mishra.

Date: February 2024

Formats: txt json html xml pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9538

This document defines metadata to support delegating the delivery ofHTTPS content between two or more interconnected Content DeliveryNetworks (CDNs). Specifically, this document defines a ContentDelivery Network Interconnection (CDNI) Metadata interface object to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC 9115. Per RFC 9115, delegating entities can remain in full control of the delegation and can revoke it at any time. This avoids the need to share private cryptographic key material between the involved entities.

RFC 9539 Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS

Authors: D. K. Gillmor, Ed., J. Salazar, Ed., P. Hoffman, Ed..

Date: February 2024

Formats: txt json xml pdf html

Status: EXPERIMENTAL

DOI: 10.17487/RFC 9539

This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The protections provided by the guidance in this document can be defeated by an active attacker, but they should be simpler and less risky to deploy than more powerful defenses.
The goal of this document is to simplify and speed up deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. Wider easy deployment of the underlying encrypted transport on an opportunistic basis may facilitate the future specification of stronger cryptographic protections against more-powerful attacks.

RFC 9540 Discovery of Oblivious Services via Service Binding Records

Authors: T. Pauly, T. Reddy.K.

Date: February 2024

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9540

This document defines a parameter that can be included in ServiceBinding (SVCB) and HTTPS DNS resource records to denote that a service is accessible using Oblivious HTTP, by offering an ObliviousGateway Resource through which to access the target. This document also defines a mechanism for learning the key configuration of the discovered Oblivious Gateway Resource.

RFC 9541 Flush Mechanism for Customer MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN)

Authors: J. Rabadan, Ed., S. Sathappan, K. Nagaraj, M. Miyake, T. Matsuda.

Date: March 2024

Formats: txt pdf xml html json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9541

Provider Backbone Bridging (PBB) can be combined with EthernetVirtual Private Networks (EVPNs) to deploy Ethernet Local AreaNetwork (E-LAN) services in large Multiprotocol Label Switching(MPLS) networks. That combination is what we refer to as "PBB-EVPN."Single-Active multihoming and per Service Instance Identifier (I-SID) load-balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active multihomed Ethernet Segments (ESs), PBB-EVPN defines a flush mechanism for Customer MACs (C-MACs) called"C-MAC flush" that works for different Ethernet Segment Backbone MAC(B-MAC) address allocation models. This document complements thoseC-MAC flush procedures for cases in which no PBB-EVPN ESs are defined(i.e., the attachment circuit is associated with a zero EthernetSegment Identifier (ESI)) and the C-MAC flush requires I-SID-level granularity.

RFC 9542 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Authors: D. Eastlake 3rd, J. Abley, Y. Li.

Date: April 2024

Formats: txt json xml pdf html

Obsoletes: RFC 7042

Also: BCP 0141

Status: BEST CURRENT PRACTICE

DOI: 10.17487/RFC 9542

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANAOrganizationally Unique Identifier (OUI), and provides some values for use in documentation. This document obsoletes RFC 7042.

RFC 9543 A Framework for Network Slices in Networks Built from IETF Technologies

Authors: A. Farrel, Ed., J. Drake, Ed., R. Rokui, S. Homma, K. Makhijani, L. Contreras, J. Tantsura.

Date: March 2024

Formats: txt json html xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9543

This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF NetworkSlice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context.
The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF NetworkSlice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security.
This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices.

RFC 9544 Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs)

Authors: G. Mirsky, J. Halpern, X. Min, A. Clemm, J. Strassner, J. François.

Date: March 2024

Formats: txt html json xml pdf

Status: INFORMATIONAL

DOI: 10.17487/RFC 9544

This document defines a set of metrics for networking services with performance requirements expressed as Service Level Objectives(SLOs). These metrics, referred to as "Precision AvailabilityMetrics (PAMs)", are useful for defining and monitoring SLOs. For example, PAMs can be used by providers and/or customers of an RFC9543 Network Slice Service to assess whether the service is provided in compliance with its defined SLOs.

RFC 9545 Path Segment Identifier in MPLS-Based Segment Routing Networks

Authors: W. Cheng, Ed., H. Li, C. Li, Ed., R. Gandhi, R. Zigler.

Date: February 2024

Formats: txt html xml json pdf

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9545

A Segment Routing (SR) path is identified by an SR segment list. A subset of segments from the segment list cannot be leveraged to distinguish one SR path from another as they may be partially congruent. SR path identification is a prerequisite for various use cases such as performance measurement and end-to-end 1+1 path protection.
In an SR over MPLS (SR-MPLS) data plane, an egress node cannot determine on which SR path a packet traversed the network from the label stack because the segment identifiers are removed from the label stack as the packet transits the network.
This document defines a Path Segment Identifier (PSID) to identify anSR path on the egress node of the path.

RFC 9546 Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the MPLS Data Plane

Authors: G. Mirsky, M. Chen, B. Varga.

Date: February 2024

Formats: txt json pdf xml html

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9546

This document defines format and usage principles of theDeterministic Networking (DetNet) service Associated Channel over aDetNet network with the MPLS data plane. The DetNet serviceAssociated Channel can be used to carry test packets of activeOperations, Administration, and Maintenance (OAM) protocols that are used to detect DetNet failures and measure performance metrics.

RFC 9547 Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022

Authors: J. Arkko, C. S. Perkins, S. Krishnan.

Date: February 2024

Formats: txt pdf xml json html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9547

Internet communications and applications have both environmental costs and benefits. The IAB ran an online workshop in December 2022 to explore and understand these impacts.
The role of the workshop was to discuss the impacts and the evolving industry needs, and to identify areas for improvements and future work. A key goal of the workshop was to call further attention to the topic and bring together a diverse stakeholder community to discuss these issues.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

RFC 9549 Internationalization Updates to RFC 5280

Authors: R. Housley.

Date: March 2024

Formats: txt pdf xml html json

Obsoletes: RFC 8399

Updates: RFC 5280

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9549

The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and includes support for internationalized email addresses in X.509 certificates. The updates ensure that name constraints for email addresses that contain only ASCII characters and internationalized email addresses are handled in the same manner. This document obsoletes RFC 8399.

RFC 9550 Deterministic Networking (DetNet): Packet Ordering Function

Authors: B. Varga, Ed., J. Farkas, S. Kehrer, T. Heer.

Date: March 2024

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9550

The replication and elimination functions of the DeterministicNetworking (DetNet) architecture can result in out-of-order packets, which is not acceptable for some time-sensitive applications. ThePacket Ordering Function (POF) algorithms described in this document enable restoration of the correct packet order when the replication and elimination functions are used in DetNet networks. The POF only provides ordering within the latency bound of a DetNet flow; it does not provide any additional reliability.

RFC 9551 Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet)

Authors: G. Mirsky, F. Theoleyre, G. Papadopoulos, CJ. Bernardos, B. Varga, J. Farkas.

Date: March 2024

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9551

Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operations, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective (SLO), such as packet delay, delay variation, and packet-loss ratio, assigned to each DetNet flow.

RFC 9552 Distribution of Link-State and Traffic Engineering Information Using BGP

Authors: K. Talaulikar, Ed..

Date: December 2023

Formats: txt json pdf xml html

Obsoletes: RFC 7752, RFC 9029

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9552

In many environments, a component external to a network is called upon to perform computations based on the network topology and the 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 aBGP Network Layer Reachability Information (NLRI) encoding format.The mechanism applies to physical and virtual (e.g., tunnel) 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).
This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752.

RFC 9556 Internet of Things (IoT) Edge Challenges and Functions

Authors: J. Hong, Y-G. Hong, X. de Foy, M. Kovatsch, E. Schooler, D. Kutscher.

Date: April 2024

Formats: txt xml json pdf html

Status: INFORMATIONAL

DOI: 10.17487/RFC 9556

Many Internet of Things (IoT) applications have requirements that cannot be satisfied by centralized cloud-based systems (i.e., cloud computing). These include time sensitivity, data volume, connectivity cost, operation in the face of intermittent services, privacy, and security. As a result, IoT is driving the Internet toward edge computing. This document outlines the requirements of the emerging IoT edge and its challenges. It presents a general model and major components of the IoT edge to provide a common basis for future discussions in the Thing-to-Thing Research Group (T2TRG) and other IRTF and IETF groups. This document is a product of theIRTF T2TRG.

RFC 9558 Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC

Authors: B. Makarenko, V. Dolmatov, Ed..

Date: April 2024

Formats: txt html xml pdf json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9558

This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in theDomain Name System Security Extensions (DNSSEC).

RFC 9561 Using the Parallel NFS (pNFS) SCSI Layout to Access Non-Volatile Memory Express (NVMe) Storage Devices

Authors: C. Hellwig, Ed., C. Lever, S. Faibish, D. Black.

Date: April 2024

Formats: txt html pdf xml json

Status: PROPOSED STANDARD

DOI: 10.17487/RFC 9561

This document specifies how to use the Parallel Network File System(pNFS) Small Computer System Interface (SCSI) Layout Type to access storage devices using the Non-Volatile Memory Express (NVMe) protocol family.

RFC 9564 Faster Than Light Speed Protocol (FLIP)

Authors: M. Blanchet.

Date: 1 April 2024

Formats: txt xml pdf html json

Status: INFORMATIONAL

DOI: 10.17487/RFC 9564

The recent advances in artificial intelligence (AI) such as large language models enable the design of the Faster than LIght speedProtocol (FLIP) for Internet. FLIP provides a way to avoid congestion, enhance security, and deliver faster packets on theInternet by using AI to predict future packets at the receiving peer before they arrive. This document describes the protocol, its various encapsulations, and some operational considerations.