Workgroup RFCs
Browse Workgroup RFCs by Number
- RFC0001 - Host Software
- RFC0002 - Host software
- RFC0003 - Documentation conventions
- RFC0004 - Network timetable
- RFC0005 - Decode Encode Language (DEL)
- RFC0006 - Conversation with Bob Kahn
- RFC0007 - Host-IMP interface
- RFC0008 - ARPA Network Functional Specifications
- RFC0009 - Host Software
- RFC0010 - Documentation conventions
- RFC0011 - Implementation of the Host - Host Software Procedures in GORDO
- RFC0012 - IMP-Host interface flow diagrams
- RFC0013 - Zero Text Length EOF Message
- RFC0015 - Network subsystem for time sharing hosts
- RFC0016 - M.I.T
- RFC0017 - Some questions re: Host-IMP Protocol
- RFC0018 - IMP-IMP and HOST-HOST Control Links
- RFC0019 - Two protocol suggestions to reduce congestion at swap bound nodes
- RFC0020 - ASCII format for network interchange
- RFC0021 - Network meeting
- RFC0022 - Host-host control message formats
- RFC0023 - Transmission of Multiple Control Messages
- RFC0024 - Documentation Conventions
- RFC0025 - No High Link Numbers
- RFC0027 - Documentation Conventions
- RFC0028 - Time Standards
- RFC0029 - Response to RFC 28
- RFC0030 - Documentation Conventions
- RFC0031 - Binary Message Forms in Computer
- RFC0032 - Some Thoughts on SRI's Proposed Real Time Clock
- RFC0033 - New Host-Host Protocol
- RFC0034 - Some Brief Preliminary Notes on the Augmentation Research Center Clock
- RFC0035 - Network Meeting
- RFC0036 - Protocol Notes
- RFC0037 - Network Meeting Epilogue, etc
- RFC0038 - Comments on Network Protocol from NWG/RFC #36
- RFC0039 - Comments on Protocol Re: NWG/RFC #36
- RFC0040 - More Comments on the Forthcoming Protocol
- RFC0041 - IMP-IMP Teletype Communication
- RFC0042 - Message Data Types
- RFC0043 - Proposed Meeting
- RFC0044 - Comments on NWG/RFC 33 and 36
- RFC0045 - New Protocol is Coming
- RFC0046 - ARPA Network protocol notes
- RFC0047 - BBN's Comments on NWG/RFC #33
- RFC0048 - Possible protocol plateau
- RFC0049 - Conversations with S. Crocker (UCLA)
- RFC0050 - Comments on the Meyer Proposal
- RFC0051 - Proposal for a Network Interchange Language
- RFC0052 - Updated distribution list
- RFC0053 - Official protocol mechanism
- RFC0054 - Official Protocol Proffering
- RFC0055 - Prototypical implementation of the NCP
- RFC0056 - Third Level Protocol: Logger Protocol
- RFC0057 - Thoughts and Reflections on NWG/RFC 54
- RFC0058 - Logical Message Synchronization
- RFC0059 - Flow Control - Fixed Versus Demand Allocation
- RFC0060 - A Simplified NCP Protocol
- RFC0061 - Note on Interprocess Communication in a Resource Sharing Computer Network
- RFC0062 - Systems for Interprocess Communication in a Resource Sharing Computer Network
- RFC0063 - Belated Network Meeting Report
- RFC0064 - Getting rid of marking
- RFC0065 - Comments on Host/Host Protocol document #1
- RFC0066 - NIC - third level ideas and other noise
- RFC0067 - Proposed Change to Host/IMP Spec to Eliminate Marking
- RFC0068 - Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM
- RFC0069 - Distribution List Change for MIT
- RFC0070 - Note on Padding
- RFC0071 - Reallocation in Case of Input Error
- RFC0072 - Proposed Moratorium on Changes to Network Protocol
- RFC0073 - Response to NWG/RFC 67
- RFC0074 - Specifications for Network Use of the UCSB On-Line System
- RFC0075 - Network Meeting
- RFC0076 - Connection by name: User oriented protocol
- RFC0077 - Network meeting report
- RFC0078 - NCP Status Report: UCSB/Rand
- RFC0079 - Logger Protocol error
- RFC0080 - Protocols and Data Formats
- RFC0081 - Request for Reference Information
- RFC0082 - Network Meeting Notes
- RFC0083 - Language-machine for data reconfiguration
- RFC0084 - List of NWG/RFC's 1-80
- RFC0085 - Network Working Group meeting
- RFC0086 - Proposal for a Network Standard Format for a Data Stream to Control Graphics Display
- RFC0087 - Topic for Discussion at the Next Network Working Group Meeting
- RFC0088 - NETRJS: A third level protocol for Remote Job Entry
- RFC0089 - Some historic moments in networking
- RFC0090 - CCN as a Network Service Center
- RFC0091 - Proposed User-User Protocol
- RFC0093 - Initial Connection Protocol
- RFC0094 - Some thoughts on Network Graphics
- RFC0095 - Distribution of NWG/RFC's through the NIC
- RFC0096 - An Interactive Network Experiment to Study Modes of Access the Network Information Center
- RFC0097 - First Cut at a Proposed Telnet Protocol
- RFC0098 - Logger Protocol Proposal
- RFC0099 - Network Meeting
- RFC0100 - Categorization and guide to NWG/RFCs
- RFC0101 - Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971
- RFC0102 - Output of the Host-Host Protocol glitch cleaning committee
- RFC0103 - Implementation of Interrupt Keys
- RFC0104 - Link 191
- RFC0105 - Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB
- RFC0106 - User/Server Site Protocol Network Host Questionnaire
- RFC0107 - Output of the Host-Host Protocol Glitch Cleaning Committee
- RFC0108 - Attendance list at the Urbana NWG meeting, February 17-19, 1971
- RFC0109 - Level III Server Protocol for the Lincoln Laboratory 360/67 Host
- RFC0110 - Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts
- RFC0111 - Pressure from the Chairman
- RFC0112 - User/Server Site Protocol: Network Host Questionnaire
- RFC0113 - Network activity report: UCSB Rand
- RFC0114 - File Transfer Protocol
- RFC0115 - Some Network Information Center policies on handling documents
- RFC0116 - Structure of the May NWG Meeting
- RFC0117 - Some comments on the official protocol
- RFC0118 - Recommendations for facility documentation
- RFC0119 - Network Fortran Subprograms
- RFC0120 - Network PL1 subprograms
- RFC0121 - Network on-line operators
- RFC0122 - Network specifications for UCSB's Simple-Minded File System
- RFC0123 - Proffered Official ICP
- RFC0124 - Typographical error in RFC 107
- RFC0125 - Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream
- RFC0126 - Graphics Facilities at Ames Research Center
- RFC0127 - Comments on RFC 123
- RFC0128 - Bytes
- RFC0129 - Request for comments on socket name structure
- RFC0130 - Response to RFC 111: Pressure from the chairman
- RFC0131 - Response to RFC 116: May NWG meeting
- RFC0132 - Typographical Error in RFC 107
- RFC0133 - File Transfer and Error Recovery
- RFC0134 - Network Graphics meeting
- RFC0135 - Response to NWG/RFC 110
- RFC0136 - Host accounting and administrative procedures
- RFC0137 - Telnet Protocol - a proposed document
- RFC0138 - Status report on proposed Data Reconfiguration Service
- RFC0139 - Discussion of Telnet Protocol
- RFC0140 - Agenda for the May NWG meeting
- RFC0141 - Comments on RFC 114: A File Transfer Protocol
- RFC0142 - Time-Out Mechanism in the Host-Host Protocol
- RFC0143 - Regarding proffered official ICP
- RFC0144 - Data sharing on computer networks
- RFC0145 - Initial Connection Protocol Control Commands
- RFC0146 - Views on issues relevant to data sharing on computer networks
- RFC0147 - Definition of a socket
- RFC0148 - Comments on RFC 123
- RFC0149 - Best Laid Plans
- RFC0150 - Use of IPC Facilities: A Working Paper
- RFC0151 - Comments on a proffered official ICP: RFCs 123, 127
- RFC0152 - SRI Artificial Intelligence status report
- RFC0153 - SRI ARC-NIC status
- RFC0154 - Exposition Style
- RFC0155 - ARPA Network mailing lists
- RFC0156 - Status of the Illinois site: Response to RFC 116
- RFC0157 - Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems
- RFC0158 - Telnet Protocol: A Proposed Document
- RFC0160 - RFC brief list
- RFC0161 - Solution to the race condition in the ICP
- RFC0162 - NETBUGGER3
- RFC0163 - Data transfer protocols
- RFC0164 - Minutes of Network Working Group meeting, 5/16 through 5/19/71
- RFC0165 - Proffered Official Initial Connection Protocol
- RFC0166 - Data Reconfiguration Service: An implementation specification
- RFC0167 - Socket conventions reconsidered
- RFC0168 - ARPA Network mailing lists
- RFC0169 - COMPUTER NETWORKS
- RFC0170 - RFC List by Number
- RFC0171 - The Data Transfer Protocol
- RFC0172 - The File Transfer Protocol
- RFC0173 - Network Data Management Committee Meeting Announcement
- RFC0174 - UCLA - Computer Science Graphics Overview
- RFC0175 - Comments on "Socket Conventions Reconsidered"
- RFC0176 - Comments on "Byte size for connections"
- RFC0177 - Device independent graphical display description
- RFC0178 - Network graphic attention handling
- RFC0179 - Link Number Assignments
- RFC0180 - File system questionnaire
- RFC0181 - Modifications to RFC 177
- RFC0182 - Compilation of list of relevant site reports
- RFC0183 - EBCDIC Codes and Their Mapping to ASCII
- RFC0184 - Proposed graphic display modes
- RFC0185 - NIC distribution of manuals and handbooks
- RFC0186 - Network graphics loader
- RFC0187 - Network/440 Protocol Concept
- RFC0188 - Data management meeting announcement
- RFC0189 - Interim NETRJS specifications
- RFC0190 - DEC PDP-10-IMLAC communications system
- RFC0191 - Graphics implementation and conceptualization at Augmentation Research Center
- RFC0192 - Some factors which a Network Graphics Protocol must consider
- RFC0193 - NETWORK CHECKOUT
- RFC0194 - The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes
- RFC0195 - Data computers-data descriptions and access language
- RFC0196 - Mail Box Protocol
- RFC0197 - Initial Connection Protocol - Reviewed
- RFC0198 - Site Certification - Lincoln Labs 360/67
- RFC0199 - Suggestions for a Network Data-Tablet Graphics Protocol
- RFC0200 - RFC list by number
- RFC0202 - Possible Deadlock in ICP
- RFC0203 - Achieving reliable communication
- RFC0204 - Sockets in use
- RFC0205 - NETCRT - a character display protocol
- RFC0206 - A User TELNET Description of an Initial Implementation
- RFC0207 - September Network Working Group meeting
- RFC0208 - Address tables
- RFC0209 - Host/IMP interface documentation
- RFC0210 - Improvement of Flow Control
- RFC0211 - ARPA Network Mailing Lists
- RFC0212 - NWG meeting on network usage
- RFC0213 - IMP System change notification
- RFC0214 - Network checkpoint
- RFC0215 - NCP, ICP, and Telnet: The Terminal IMP implementation
- RFC0216 - Telnet Access to UCSB's On-Line System
- RFC0217 - Specifications changes for OLS, RJE/RJOR, and SMFS
- RFC0218 - Changing the IMP status reporting facility
- RFC0219 - User's View of the Datacomputer
- RFC0221 - Mail Box Protocol: Version 2
- RFC0222 - Subject: System programmer's workshop
- RFC0223 - Network Information Center schedule for network users
- RFC0224 - Comments on Mailbox Protocol
- RFC0225 - Rand/UCSB network graphics experiment
- RFC0226 - Standardization of host mnemonics
- RFC0227 - Data transfer rates (Rand/UCLA)
- RFC0228 - Clarification
- RFC0229 - Standard host names
- RFC0230 - Toward reliable operation of minicomputer-based terminals on a TIP
- RFC0231 - Service center standards for remote usage: A user's view
- RFC0232 - Postponement of network graphics meeting
- RFC0233 - Standardization of host call letters
- RFC0234 - Network Working Group meeting schedule
- RFC0235 - Site status
- RFC0236 - Standard host names
- RFC0237 - NIC view of standard host names
- RFC0238 - Comments on DTP and FTP proposals
- RFC0239 - Host mnemonics proposed in RFC 226 (NIC 7625)
- RFC0240 - Site Status
- RFC0241 - Connecting computers to MLC ports
- RFC0242 - Data Descriptive Language for Shared Data
- RFC0243 - Network and data sharing bibliography
- RFC0245 - Reservations for Network Group meeting
- RFC0246 - Network Graphics meeting
- RFC0247 - Proffered set of standard host names
- RFC0249 - Coordination of equipment and supplies purchase
- RFC0250 - Some thoughts on file transfer
- RFC0251 - Weather data
- RFC0252 - Network host status
- RFC0253 - Second Network Graphics meeting details
- RFC0254 - Scenarios for using ARPANET computers
- RFC0255 - Status of network hosts
- RFC0256 - IMPSYS change notification
- RFC0263 - "Very Distant" Host interface
- RFC0264 - The Data Transfer Protocol
- RFC0265 - The File Transfer Protocol
- RFC0266 - Network host status
- RFC0267 - Network Host Status
- RFC0268 - Graphics facilities information
- RFC0269 - Some Experience with File Transfer
- RFC0270 - Correction to BBN Report No. 1822 (NIC NO 7958)
- RFC0271 - IMP System change notifications
- RFC0273 - More on standard host names
- RFC0274 - Establishing a local guide for network usage
- RFC0276 - NIC course
- RFC0278 - Revision of the Mail Box Protocol
- RFC0280 - A Draft of Host Names
- RFC0281 - Suggested addition to File Transfer Protocol
- RFC0282 - Graphics meeting report
- RFC0283 - NETRJT: Remote Job Service Protocol for TIPS
- RFC0285 - Network graphics
- RFC0286 - Network Library Information System
- RFC0287 - Status of Network Hosts
- RFC0288 - Network host status
- RFC0289 - What we hope is an official list of host names
- RFC0290 - Computer networks and data sharing: A bibliography
- RFC0291 - Data Management Meeting Announcement
- RFC0292 - Graphics Protocol: Level 0 only
- RFC0293 - Network Host Status
- RFC0294 - The Use of "Set Data Type" Transaction in File Transfer Protocol
- RFC0295 - Report of the Protocol Workshop, 12 October 1971
- RFC0296 - DS-1 Display System
- RFC0297 - TIP Message Buffers
- RFC0298 - Network host status
- RFC0299 - Information Management System
- RFC0300 - ARPA Network mailing lists
- RFC0301 - BBN IMP (#5) and NCC Schedule March 4, 1971
- RFC0302 - Exercising The ARPANET
- RFC0303 - ARPA Network mailing lists
- RFC0304 - Data Management System Proposal for the ARPA Network
- RFC0305 - Unknown Host Numbers
- RFC0306 - Network host status
- RFC0307 - Using network Remote Job Entry
- RFC0308 - ARPANET host availability data
- RFC0309 - Data and File Transfer Workshop Announcement
- RFC0310 - Another Look at Data and File Transfer Protocols
- RFC0311 - New Console Attachments to the USCB Host
- RFC0312 - Proposed Change in IMP-to-Host Protocol
- RFC0313 - Computer based instruction
- RFC0314 - Network Graphics Working Group Meeting
- RFC0315 - Network Host Status
- RFC0316 - ARPA Network Data Management Working Group
- RFC0317 - Official Host-Host Protocol Modification: Assigned Link Numbers
- RFC0318 - Telnet Protocols
- RFC0319 - Network Host Status
- RFC0320 - Workshop on Hard Copy Line Graphics
- RFC0321 - CBI Networking Activity at MITRE
- RFC0322 - Well known socket numbers
- RFC0323 - Formation of Network Measurement Group (NMG)
- RFC0324 - RJE Protocol meeting
- RFC0325 - Network Remote Job Entry program - NETRJS
- RFC0326 - Network Host Status
- RFC0327 - Data and File Transfer workshop notes
- RFC0328 - Suggested Telnet Protocol Changes
- RFC0329 - ARPA Network Mailing Lists
- RFC0330 - Network Host Status
- RFC0331 - IMP System Change Notification
- RFC0332 - Network Host Status
- RFC0333 - Proposed experiment with a Message Switching Protocol
- RFC0334 - Network Use on May 8
- RFC0335 - New Interface - IMP/360
- RFC0336 - Level 0 Graphic Input Protocol
- RFC0338 - EBCDIC/ASCII Mapping for Network RJE
- RFC0339 - MLTNET: A "Multi Telnet" Subsystem for Tenex
- RFC0340 - Proposed Telnet Changes
- RFC0342 - Network Host Status
- RFC0343 - IMP System change notification
- RFC0344 - Network Host Status
- RFC0345 - Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN)
- RFC0346 - Satellite Considerations
- RFC0347 - Echo process
- RFC0348 - Discard Process
- RFC0349 - Proposed Standard Socket Numbers
- RFC0350 - User Accounts for UCSB On-Line System
- RFC0351 - Graphics information form for the ARPANET graphics resources notebook
- RFC0352 - TIP Site Information Form
- RFC0353 - Network host status
- RFC0354 - File Transfer Protocol
- RFC0355 - Response to NWG/RFC 346
- RFC0356 - ARPA Network Control Center
- RFC0357 - Echoing strategy for satellite links
- RFC0359 - Status of the Release of the New IMP System (2600)
- RFC0360 - Proposed Remote Job Entry Protocol
- RFC0361 - Deamon Processes on Host 106
- RFC0362 - Network Host Status
- RFC0363 - ARPA Network mailing lists
- RFC0364 - Serving remote users on the ARPANET
- RFC0365 - Letter to All TIP Users
- RFC0366 - Network Host Status
- RFC0367 - Network host status
- RFC0368 - Comments on "Proposed Remote Job Entry Protocol"
- RFC0369 - Evaluation of ARPANET services January-March, 1972
- RFC0370 - Network Host Status
- RFC0371 - Demonstration at International Computer Communications Conference
- RFC0372 - Notes on a Conversation with Bob Kahn on the ICCC
- RFC0373 - Arbitrary Character Sets
- RFC0374 - IMP System Announcement
- RFC0376 - Network Host Status
- RFC0377 - Using TSO via ARPA Network Virtual Terminal
- RFC0378 - Traffic statistics (July 1972)
- RFC0379 - Using TSO at CCN
- RFC0381 - Three aids to improved network operation
- RFC0382 - Mathematical Software on the ARPA Network
- RFC0384 - Official site idents for organizations in the ARPA Network
- RFC0385 - Comments on the File Transfer Protocol
- RFC0386 - Letter to TIP users-2
- RFC0387 - Some experiences in implementing Network Graphics Protocol Level 0
- RFC0388 - NCP statistics
- RFC0389 - UCLA Campus Computing Network Liaison Staff for ARPA Network
- RFC0390 - TSO Scenario
- RFC0391 - Traffic statistics (August 1972)
- RFC0392 - Measurement of host costs for transmitting network data
- RFC0393 - Comments on Telnet Protocol Changes
- RFC0394 - Two Proposed Changes to the IMP-Host Protocol
- RFC0395 - Switch Settings on IMPs and TIPs
- RFC0396 - Network Graphics Working Group Meeting - Second Iteration
- RFC0398 - UCSB Online Graphics
- RFC0399 - SMFS Login and Logout
- RFC0400 - Traffic Statistics (September 1972)
- RFC0401 - Conversion of NGP-0 Coordinates to Device Specific Coordinates
- RFC0402 - ARPA Network Mailing Lists
- RFC0403 - Desirability of a Network 1108 Service
- RFC0404 - Host Address Changes Involving Rand and ISI
- RFC0405 - Correction to RFC 404
- RFC0406 - Scheduled IMP Software Releases
- RFC0407 - Remote Job Entry Protocol
- RFC0408 - NETBANK
- RFC0409 - Tenex interface to UCSB's Simple-Minded File System
- RFC0410 - Removal of the 30-Second Delay When Hosts Come Up
- RFC0411 - New MULTICS Network Software Features
- RFC0412 - User FTP Documentation
- RFC0413 - Traffic statistics (October 1972)
- RFC0414 - File Transfer Protocol (FTP) status and further comments
- RFC0415 - Tenex bandwidth
- RFC0416 - ARC System Will Be Unavailable for Use During Thanksgiving Week
- RFC0417 - Link usage violation
- RFC0418 - Server File Transfer Under TSS/360 At NASA-Ames Research Center
- RFC0419 - To: Network liaisons and station agents
- RFC0420 - CCA ICCC weather demo
- RFC0421 - Software Consulting Service for Network Users
- RFC0422 - Traffic statistics (November 1972)
- RFC0423 - UCLA Campus Computing Network Liaison Staff for ARPANET
- RFC0425 - "But my NCP costs $500 a day"
- RFC0426 - Reconnection Protocol
- RFC0429 - Character Generator Process
- RFC0430 - Comments on File Transfer Protocol
- RFC0431 - Update on SMFS Login and Logout
- RFC0432 - Network logical map
- RFC0433 - Socket number list
- RFC0434 - IMP/TIP memory retrofit schedule
- RFC0435 - Telnet issues
- RFC0436 - Announcement of RJS at UCSB
- RFC0437 - Data Reconfiguration Service at UCSB
- RFC0438 - FTP server-server interaction
- RFC0439 - PARRY encounters the DOCTOR
- RFC0440 - Scheduled network software maintenance
- RFC0441 - Inter-Entity Communication - an experiment
- RFC0442 - Current flow-control scheme for IMPSYS
- RFC0443 - Traffic statistics (December 1972)
- RFC0445 - IMP/TIP preventive maintenance schedule
- RFC0446 - Proposal to consider a network program resource notebook
- RFC0447 - IMP/TIP memory retrofit schedule
- RFC0448 - Print files in FTP
- RFC0449 - Current flow-control scheme for IMPSYS
- RFC0450 - MULTICS sampling timeout change
- RFC0451 - Tentative proposal for a Unified User Level Protocol
- RFC0452 - TELNET Command at Host LL
- RFC0453 - Meeting announcement to discuss a network mail system
- RFC0454 - File Transfer Protocol - meeting announcement and a new proposed document
- RFC0455 - Traffic statistics (January 1973)
- RFC0456 - Memorandum: Date change of mail meeting
- RFC0457 - TIPUG
- RFC0458 - Mail retrieval via FTP
- RFC0459 - Network questionnaires
- RFC0460 - NCP survey
- RFC0461 - Telnet Protocol meeting announcement
- RFC0462 - Responding to user needs
- RFC0463 - FTP comments and response to RFC 430
- RFC0464 - Resource notebook framework
- RFC0466 - Telnet logger/server for host LL-67
- RFC0467 - Proposed change to Host-Host Protocol: Resynchronization of connection status
- RFC0468 - FTP data compression
- RFC0469 - Network mail meeting summary
- RFC0470 - Change in socket for TIP news facility
- RFC0471 - Workshop on multi-site executive programs
- RFC0472 - Illinois' reply to Maxwell's request for graphics information (NIC 14925)
- RFC0473 - MIX and MIXAL?
- RFC0474 - Announcement of NGWG meeting: Call for papers
- RFC0475 - FTP and Network Mail System
- RFC0476 - IMP/TIP memory retrofit schedule (rev 2)
- RFC0477 - Remote Job Service at UCSB
- RFC0478 - FTP server-server interaction - II
- RFC0479 - Use of FTP by the NIC Journal
- RFC0480 - Host-dependent FTP parameters
- RFC0482 - Traffic statistics (February 1973)
- RFC0483 - Cancellation of the resource notebook framework meeting
- RFC0485 - MIX and MIXAL at UCSB
- RFC0486 - Data transfer revisited
- RFC0487 - Free file transfer
- RFC0488 - NLS classes at network sites
- RFC0489 - Comment on resynchronization of connection status proposal
- RFC0490 - Surrogate RJS for UCLA-CCN
- RFC0491 - What is "Free"?
- RFC0492 - Response to RFC 467
- RFC0493 - GRAPHICS PROTOCOL
- RFC0494 - Availability of MIX and MIXAL in the Network
- RFC0495 - Telnet Protocol specifications
- RFC0496 - TNLS quick reference card is available
- RFC0497 - Traffic Statistics (March 1973)
- RFC0498 - On mail service to CCN
- RFC0499 - Harvard's network RJE
- RFC0500 - Integration of data management systems on a computer network
- RFC0501 - Un-muddling "free file transfer"
- RFC0503 - Socket number list
- RFC0504 - Distributed resources workshop announcement
- RFC0505 - Two solutions to a file transfer access problem
- RFC0506 - FTP command naming problem
- RFC0508 - Real-time data transmission on the ARPANET
- RFC0509 - Traffic statistics (April 1973)
- RFC0510 - Request for network mailbox addresses
- RFC0511 - Enterprise phone service to NIC from ARPANET sites
- RFC0512 - More on lost message detection
- RFC0513 - Comments on the new Telnet specifications
- RFC0514 - Network make-work
- RFC0515 - Specifications for Datalanguage, Version 0/9
- RFC0516 - Lost message detection
- RFC0518 - ARPANET accounts
- RFC0519 - Resource Evaluation
- RFC0520 - Memo to FTP group: Proposal for File Access Protocol
- RFC0521 - Restricted use of IMP DDT
- RFC0522 - Traffic Statistics (May 1973)
- RFC0523 - SURVEY is in operation again
- RFC0524 - Proposed Mail Protocol
- RFC0525 - MIT-MATHLAB meets UCSB-OLS -an example of resource sharing
- RFC0526 - Technical meeting: Digital image processing software systems
- RFC0527 - ARPAWOCKY
- RFC0528 - Software checksumming in the IMP and network reliability
- RFC0529 - Note on protocol synch sequences
- RFC0530 - Report on the Survey Project
- RFC0531 - Feast or famine? A response to two recent RFC's about network information
- RFC0532 - UCSD-CC Server-FTP facility
- RFC0533 - Message-ID numbers
- RFC0534 - Lost message detection
- RFC0535 - Comments on File Access Protocol
- RFC0537 - Announcement of NGG meeting July 16-17
- RFC0538 - Traffic statistics (June 1973)
- RFC0539 - Thoughts on the mail protocol proposed in RFC 524
- RFC0542 - File Transfer Protocol
- RFC0543 - Network journal submission and delivery
- RFC0544 - Locating on-line documentation at SRI-ARC
- RFC0545 - Of what quality be the UCSB resources evaluators?
- RFC0546 - Tenex load averages for July 1973
- RFC0547 - Change to the Very Distant Host specification
- RFC0548 - Hosts using the IMP Going Down message
- RFC0549 - Minutes of Network Graphics Group meeting, 15-17 July 1973
- RFC0550 - NIC NCP experiment
- RFC0551 - NYU, ANL, and LBL Joining the Net
- RFC0552 - Single access to standard protocols
- RFC0553 - Draft design for a text/graphics protocol
- RFC0555 - Responses to critiques of the proposed mail protocol
- RFC0556 - Traffic Statistics (July 1973)
- RFC0557 - REVELATIONS IN NETWORK HOST MEASUREMENTS
- RFC0559 - Comments on The New Telnet Protocol and its Implementation
- RFC0560 - Remote Controlled Transmission and Echoing Telnet option
- RFC0561 - Standardizing Network Mail Headers
- RFC0562 - Modifications to the TELNET Specification
- RFC0563 - Comments on the RCTE Telnet option
- RFC0565 - Storing network survey data at the datacomputer
- RFC0566 - Traffic statistics (August 1973)
- RFC0567 - Cross Country Network Bandwidth
- RFC0568 - Response to RFC 567 - cross country network bandwidth
- RFC0569 - NETED: A Common Editor for the ARPA Network
- RFC0570 - Experimental input mapping between NVT ASCII and UCSB On Line System
- RFC0571 - TENEX FTP PROBLEM
- RFC0573 - DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS
- RFC0574 - Announcement of a Mail Facility at UCSB
- RFC0576 - Proposal for modifying linking
- RFC0577 - Mail priority
- RFC0578 - Using MIT-Mathlab MACSYMA from MIT-DMS Muddle
- RFC0579 - Traffic statistics (September 1973)
- RFC0580 - Note to Protocol Designers and Implementers
- RFC0581 - Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option
- RFC0582 - Comments on RFC 580: Machine readable protocols
- RFC0584 - Charter for ARPANET Users Interest Working Group
- RFC0585 - ARPANET users interest working group meeting
- RFC0586 - Traffic statistics (October 1973)
- RFC0587 - Announcing New Telnet Options
- RFC0588 - London Node Is Now Up
- RFC0589 - CCN NETRJS server messages to remote user
- RFC0590 - MULTICS address change
- RFC0591 - Addition to the Very Distant Host specifications
- RFC0592 - Some thoughts on system design to facilitate resource sharing
- RFC0593 - Telnet and FTP implementation schedule change
- RFC0594 - Speedup of Host-IMP interface
- RFC0595 - Second thoughts in defense of the Telnet Go-Ahead
- RFC0596 - Second thoughts on Telnet Go-Ahead
- RFC0597 - Host status
- RFC0598 - RFC index - December 5, 1973
- RFC0599 - Update on NETRJS
- RFC0600 - Interfacing an Illinois plasma terminal to the ARPANET
- Discusses some unusual interface issues for the Plato terminal.
- RFC0601 - Traffic statistics (November 1973)
- RFC0602 - "The stockings were hung by the chimney with care"
- Susceptibility of ARPANET to security violations.
- RFC0603 - Response to RFC 597: Host status
- Questions about the ARPANET topology described in RFC 597.
- RFC0604 - Assigned link numbers
- Modifies official host-host protocol. Replaces RFC 377.
- RFC0606 - Host names on-line
- Resolving differences in hostname-address mappings; see also RFCs 627, 625, 623 and 608.
- RFC0607 - Comments on the File Transfer Protocol
- An old version; see RFC 624; see also RFCs 614, 542 and 640.
- RFC0608 - Host names on-line
- Response to RFC 606; see also RFCs 627, 625 and 623.
- RFC0609 - Statement of upcoming move of NIC/NLS service
- See also RFCs 621 and 620.
- RFC0610 - Further datalanguage design concepts
- Preliminary results of the language design; a model for data languagea semantics; future considerations.
- RFC0611 - Two changes to the IMP/Host Protocol to improve user/network communications
- Expansion of Host-Going-Down and addition of Dead-Host-Status Message.
- RFC0612 - Traffic statistics (December 1973)
- RFC0613 - Network connectivity: A response to RFC 603
- RFC0614 - Response to RFC 607: "Comments on the File Transfer Protocol"
- See also RFCs 624, 542 and 640.
- RFC0615 - Proposed Network Standard Data Pathname syntax
- RFC0616 - LATEST NETWORK MAPS
- RFC0617 - Note on socket number assignment
- Danger of imposing more fixed socket number requirements; see also RFCs 542, 503 and 451.
- RFC0618 - Few observations on NCP statistics
- Distribution of NCP and IMP message types by actual measurement.
- RFC0619 - Mean round-trip times in the ARPANET
- Actual measurements of round-trip times.
- RFC0620 - Request for monitor host table updates
- In conjunction with moving NIC users to OFFICE-1; see also RFCs 621 and 609.
- RFC0621 - NIC user directories at SRI ARC
- See also RFCs 620 and 609.
- RFC0622 - Scheduling IMP/TIP down time
- Modification of previous policy.
- RFC0623 - Comments on on-line host name service
- See also RFCs 627, 625, 608 and 606.
- RFC0624 - Comments on the File Transfer Protocol
- Design changes and slight modifications. Replaces RFC 607; see also RFCs 614, 542 and 640.
- RFC0625 - On-line hostnames service
- See also RFCs 606, 608, 623 and 627.
- RFC0626 - On a possible lockup condition in IMP subnet due to message sequencing
- RFC0627 - ASCII text file of hostnames
- See also RFCs 606, 608, 623 and 625.
- RFC0628 - Status of RFC numbers and a note on pre-assigned journal numbers
- RFC0629 - Scenario for using the Network Journal
- RFC0630 - FTP error code usage for more reliable mail service
- Describes FTP reply-code usage in TENEX mail processing.
- RFC0631 - International meeting on minicomputers and data communication: Call for papers
- RFC0632 - Throughput degradations for single packet messages
- RFC0633 - IMP/TIP preventive maintenance schedule
- An old version; see RFC 638.
- RFC0634 - Change in network address for Haskins Lab
- RFC0635 - Assessment of ARPANET protocols
- Theoretical and practical motivation for redesign. Multipacket messages; host retransmission; duplicate detection; sequencing; acknowledgement.
- RFC0636 - TIP/Tenex reliability improvements
- Obtaining/maintaining connections; recovery from lost connections; connection-state changes.
- RFC0637 - Change of network address for SU-DSL
- RFC0638 - IMP/TIP preventive maintenance schedule
- Corrects RFC 633.
- RFC0640 - Revised FTP reply codes
- Updates RFC 542.
- RFC0642 - Ready line philosophy and implementation
- RFC0643 - Network Debugging Protocol
- To be used in an implementation of a PDP-11 network bootstrap device and a cross-network debugger.
- RFC0644 - On the problem of signature authentication for network mail
- RFC0645 - Network Standard Data Specification syntax
- Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615.
- RFC0647 - Proposed protocol for connecting host computers to ARPA-like networks via front end processors
- Approaches to Front-End protocol processing using available hardware and software.
- RFC0651 - Revised Telnet status option
- RFC0652 - Telnet output carriage-return disposition option
- RFC0653 - Telnet output horizontal tabstops option
- RFC0654 - Telnet output horizontal tab disposition option
- RFC0655 - Telnet output formfeed disposition option
- RFC0656 - Telnet output vertical tabstops option
- RFC0657 - Telnet output vertical tab disposition option
- RFC0658 - Telnet output linefeed disposition
- RFC0659 - Announcing additional Telnet options
- Options defined in RFCs 651-658.
- RFC0660 - Some changes to the IMP and the IMP/Host interface
- Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.
- RFC0661 - Protocol information
- An old version; see RFC 694.
- RFC0662 - Performance improvement in ARPANET file transfers from Multics
- Experimenting with host output buffers to improve throughput.
- RFC0663 - Lost message detection and recovery protocol
- Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.
- RFC0666 - Specification of the Unified User-Level Protocol
- Discusses and proposes a common command language.
- RFC0667 - Host Ports
- Approved scheme to connect host ports to the network.
- RFC0669 - November, 1974, survey of New-Protocol Telnet servers
- An earlier poll of Telnet server implementation status. Updates RFC 702; see also RFCs 703 and 679.
- RFC0671 - Note on Reconnection Protocol
- Experience with implementation in RSEXEC context.
- RFC0672 - Multi-site data collection facility
- Applicability of TIP/TENEX protocols beyond TIP accounting.
- RFC0674 - Procedure call documents: Version 2
- 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.
- RFC0675 - Specification of Internet Transmission Control Program
- The first detailed specification of TCP; see RFC 793.
- RFC0677 - Maintenance of duplicate databases
- RFC0678 - Standard file formats
- For transmission of documents across different environments.
- RFC0679 - February, 1975, survey of New-Protocol Telnet servers
- An earlier poll of Telnet server implementation status. Updates RFCs 701, 702 and 669; see also RFC 703.
- RFC0680 - Message Transmission Protocol
- Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822.
- RFC0681 - Network UNIX
- Capabilities as an ARPANET Mini-Host: standard I/O, Telnet, NCP, Hardware/Software requirements, reliability, availability.
- RFC0683 - FTPSRV - Tenex extension for paged files
- Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability.
- RFC0684 - Commentary on procedure calling as a network protocol
- Issues in designing distributed computing systems. Shortcomings of RFC 674; see also RFCs 542 and 354.
- RFC0685 - Response time in cross network debugging
- The contribution of ARPANET communication to response time.
- RFC0686 - Leaving well enough alone
- Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.
- RFC0687 - IMP/Host and Host/IMP Protocol changes
- Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692.
- RFC0688 - Tentative schedule for the new Telnet implementation for the TIP
- RFC0689 - Tenex NCP finite state machine for connections
- Describes the internal states of an NCP connection in the TENEX implementation.
- RFC0690 - Comments on the proposed Host/IMP Protocol changes
- Comments on suggestions in RFC 687; see also RFCs 692 and 696.
- RFC0691 - One more try on the FTP
- Slight revision of RFC 686, on the subject of print files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354.
- RFC0692 - Comments on IMP/Host Protocol changes (RFCs 687 and 690)
- A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687.
- RFC0694 - Protocol information
- References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661.
- RFC0695 - Official change in Host-Host Protocol
- Corrects ambiguity concerning the ERR command; changes NIC 8246 and NIC 7104.
- RFC0696 - Comments on the IMP/Host and Host/IMP Protocol changes
- Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690, 687.
- RFC0697 - CWD command of FTP
- Discusses FTP login access to "files only" directories.
- RFC0698 - Telnet extended ASCII option
- Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.
- RFC0699 - Request For Comments summary notes: 600-699
- RFC0700 - Protocol experiment
- RFC0701 - August, 1974, survey of New-Protocol Telnet servers
- RFC0702 - September, 1974, survey of New-Protocol Telnet servers
- RFC0703 - July, 1975, survey of New-Protocol Telnet Servers
- RFC0704 - IMP/Host and Host/IMP Protocol change
- RFC0705 - Front-end Protocol B6700 version
- RFC0706 - On the junk mail problem
- RFC0707 - High-level framework for network-based resource sharing
- RFC0708 - Elements of a Distributed Programming System
- RFC0712 - Distributed Capability Computing System (DCCS)
- RFC0713 - MSDTP-Message Services Data Transmission Protocol
- RFC0714 - Host-Host Protocol for an ARPANET-Type Network
- RFC0716 - Interim Revision to Appendix F of BBN 1822
- RFC0717 - Assigned Network Numbers
- RFC0718 - Comments on RCTE from the Tenex Implementation Experience
- RFC0719 - Discussion on RCTE
- RFC0720 - Address Specification Syntax for Network Mail
- RFC0721 - Out-of-Band Control Signals in a Host-to-Host Protocol
- RFC0722 - Thoughts on Interactions in Distributed Services
- RFC0724 - Proposed official standard for the format of ARPA Network messages
- RFC0725 - RJE protocol for a resource sharing network
- RFC0726 - Remote Controlled Transmission and Echoing Telnet option
- RFC0727 - Telnet logout option
- RFC0728 - Minor pitfall in the Telnet Protocol
- RFC0729 - Telnet byte macro option
- RFC0730 - Extensible field addressing
- RFC0731 - Telnet Data Entry Terminal option
- RFC0732 - Telnet Data Entry Terminal option
- RFC0733 - Standard for the format of ARPA network text messages
- RFC0734 - SUPDUP Protocol
- RFC0735 - Revised Telnet byte macro option
- RFC0736 - Telnet SUPDUP option
- RFC0737 - FTP extension: XSEN
- RFC0738 - Time server
- RFC0739 - Assigned numbers
- RFC0740 - NETRJS Protocol
- RFC0741 - Specifications for the Network Voice Protocol (NVP)
- RFC0742 - NAME/FINGER Protocol
- RFC0743 - FTP extension: XRSQ/XRCP
- RFC0744 - MARS - a Message Archiving and Retrieval Service
- RFC0745 - JANUS interface specifications
- RFC0746 - SUPDUP graphics extension
- RFC0747 - Recent extensions to the SUPDUP Protocol
- RFC0748 - Telnet randomly-lose option
- RFC0749 - Telnet SUPDUP-Output option
- RFC0750 - Assigned numbers
- RFC0751 - Survey of FTP mail and MLFL
- RFC0752 - Universal host table
- RFC0753 - Internet Message Protocol
- RFC0754 - Out-of-net host addresses for mail
- RFC0755 - Assigned numbers
- RFC0756 - NIC name server - a datagram-based information utility
- RFC0757 - Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems
- RFC0758 - Assigned numbers
- RFC0759 - Internet Message Protocol
- RFC0760 - DoD standard Internet Protocol
- RFC0761 - DoD standard Transmission Control Protocol
- RFC0762 - Assigned numbers
- RFC0763 - Role mailboxes
- RFC0764 - Telnet Protocol specification
- RFC0765 - File Transfer Protocol specification
- RFC0766 - Internet Protocol Handbook: Table of contents
- RFC0767 - Structured format for transmission of multi-media documents
- RFC0768 - User Datagram Protocol
- RFC0769 - Rapicom 450 facsimile file format
- RFC0770 - Assigned numbers
- RFC0771 - Mail transition plan
- RFC0772 - Mail Transfer Protocol
- RFC0773 - Comments on NCP/TCP mail service transition strategy
- RFC0774 - Internet Protocol Handbook: Table of contents
- RFC0775 - Directory oriented FTP commands
- RFC0776 - Assigned numbers
- RFC0777 - Internet Control Message Protocol
- RFC0778 - DCNET Internet Clock Service
- RFC0779 - Telnet send-location option
- RFC0780 - Mail Transfer Protocol
- RFC0781 - Specification of the Internet Protocol (IP) timestamp option
- RFC0782 - Virtual Terminal management model
- RFC0783 - TFTP Protocol (revision 2)
- RFC0784 - Mail Transfer Protocol: ISI TOPS20 implementation
- RFC0785 - Mail Transfer Protocol: ISI TOPS20 file definitions
- RFC0786 - Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface
- RFC0787 - Connectionless data transmission survey/tutorial
- RFC0788 - Simple Mail Transfer Protocol
- RFC0789 - Vulnerabilities of network control protocols: An example
- RFC0790 - Assigned numbers
- RFC0791 - Internet Protocol
- RFC0792 - Internet Control Message Protocol
- RFC0793 - Transmission Control Protocol
- RFC0794 - Pre-emption
- RFC0795 - Service mappings
- RFC0796 - Address mappings
- RFC0797 - Format for Bitmap files
- RFC0798 - Decoding facsimile data from the Rapicom 450
- RFC0799 - Internet name domains
- RFC0800 - Request For Comments summary notes: 700-799
- 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.
- RFC0801 - NCP/TCP transition plan
- 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.
- RFC0802 - ARPANET 1822L Host Access Protocol
- This document proposed two major changes to the current ARPANET host access protocol. The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds). See RFCs 852 and 851.
- RFC0803 - Dacom 450/500 facsimile data transcoding
- 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.
- RFC0804 - CCITT draft recommendation T.4
- This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data.
- RFC0805 - Computer mail meeting notes
- 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.
- RFC0806 - Proposed Federal Information Processing Standard: Specification for message format for computer based message systems
- 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.
- RFC0807 - Multimedia mail meeting notes
- 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.
- RFC0808 - Summary of computer mail services meeting held at BBN on 10 January 1979
- 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.
- RFC0809 - UCL facsimile system
- 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.
- RFC0810 - DoD Internet host table specification
- This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608.
- RFC0811 - Hostnames Server
- 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.
- RFC0812 - NICNAME/WHOIS
- This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it. This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory.
- RFC0813 - Window and Acknowledgement Strategy in TCP
- This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended.
- RFC0814 - Name, addresses, ports, and routes
- 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.
- RFC0815 - IP datagram reassembly algorithms
- 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.
- RFC0816 - Fault isolation and recovery
- This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.
- RFC0817 - Modularity and efficiency in protocol implementation
- This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.
- RFC0818 - Remote User Telnet service
- This RFC is the specification of an application protocol. Any host that implements this application level service must follow this protocol.
- RFC0819 - The Domain Naming Convention for Internet User Applications
- 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.
- RFC0820 - Assigned numbers
- This RFC is an old version, see RFC 870.
- RFC0821 - Simple Mail Transfer Protocol
- The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772.
- RFC0822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
- This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952.
- RFC0823 - DARPA Internet gateway
- 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.
- RFC0824 - CRONUS Virtual Local Network
- 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.
- RFC0825 - Request for comments on Requests For Comments
- This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future. It is in a sense a specification for RFCs.
- RFC0826 - An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware
- The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard.
- RFC0827 - Exterior Gateway Protocol (EGP)
- 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.
- RFC0828 - Data communications: IFIP's international "network" of experts
- 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.
- RFC0829 - Packet satellite technology reference sources
- 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.
- RFC0830 - Distributed system for Internet name service
- 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.
- RFC0831 - Backup access to the European side of SATNET
- 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.
- RFC0832 - Who talks TCP?
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82.
- RFC0833 - Who talks TCP?
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82.
- RFC0834 - Who talks TCP?
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 22-Dec-82.
- RFC0835 - Who talks TCP?
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 28-Dec-82 through 5-Jan-83.
- RFC0836 - Who talks TCP?
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 20-Dec-82. The tests were run on 4-Jan-83 through 5-Jan-83.
- RFC0837 - Who talks TCP?
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 11-Jan-83.
- RFC0838 - Who talks TCP?
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 18-Jan-83.
- RFC0839 - Who talks TCP?
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 25-Jan-83.
- RFC0840 - Official protocols
- This RFC has been revised, see RFC 880.
- RFC0841 - Specification for message format for Computer Based Message Systems
- 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.
- RFC0842 - Who talks TCP? - survey of 1 February 83
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA.
- RFC0843 - Who talks TCP? - survey of 8 February 83
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA.
- RFC0844 - Who talks ICMP, too? - Survey of 18 February 1983
- 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.
- RFC0845 - Who talks TCP? - survey of 15 February 1983
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 from ISI-VAXA.ARPA.
- RFC0846 - Who talks TCP? - survey of 22 February 1983
- This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83 from ISI-VAXA.ARPA.
- RFC0847 - Summary of Smallberg surveys
- 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).
- RFC0848 - Who provides the "little" TCP services?
- 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.
- RFC0849 - Suggestions for improved host table distribution
- 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.
- RFC0850 - Standard for interchange of USENET messages
- This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on.
- RFC0851 - ARPANET 1822L Host Access Protocol
- This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. Obsoletes RFC 802.
- RFC0852 - ARPANET short blocking feature
- 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.
- RFC0854 - Telnet Protocol Specification
- This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet. The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation). This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 18639.
- RFC0855 - Telnet Option Specifications
- 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.
- RFC0856 - Telnet Binary Transmission
- 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.
- RFC0857 - Telnet Echo Option
- 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.
- RFC0858 - Telnet Suppress Go Ahead Option
- 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.
- RFC0859 - Telnet Status Option
- 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).
- RFC0860 - Telnet Timing Mark Option
- 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.
- RFC0861 - Telnet Extended Options: List Option
- 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.
- RFC0862 - Echo Protocol
- 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.
- RFC0863 - Discard Protocol
- 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.
- RFC0864 - Character Generator Protocol
- 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.
- RFC0865 - Quote of the Day Protocol
- 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.
- RFC0866 - Active users
- 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.
- RFC0867 - Daytime Protocol
- 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.
- RFC0868 - Time Protocol
- 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.
- RFC0869 - Host Monitoring Protocol
- 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.
- RFC0870 - Assigned numbers
- This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604.
- RFC0871 - Perspective on the ARPANET reference model
- 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.
- RFC0872 - TCP-on-a-LAN
- 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.
- RFC0873 - Illusion of vendor support
- 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.
- RFC0874 - Critique of X.25
- 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.
- RFC0875 - Gateways, architectures, and heffalumps
- 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.
- RFC0876 - Survey of SMTP implementations
- 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.
- RFC0877 - Standard for the transmission of IP datagrams over public data networks
- This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks.
- RFC0878 - ARPANET 1822L Host Access Protocol
- This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other.
- RFC0879 - The TCP Maximum Segment Size and Related Topics
- This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers".
- RFC0880 - Official protocols
- This RFC identifies the documents specifying the official protocols used in the ARPA Internet. Annotations identify any revisions or changes planned. Obsoletes RFC 840.
- RFC0881 - Domain names plan and schedule
- 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.
- RFC0882 - Domain names: Concepts and facilities
- This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities.
- RFC0883 - Domain names: Implementation specification
- This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software.
- RFC0884 - Telnet terminal type option
- This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol.
- RFC0885 - Telnet end of record option
- 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.
- RFC0886 - Proposed standard for message header munging
- 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.
- RFC0887 - Resource Location Protocol
- 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.
- RFC0888 - "STUB" Exterior Gateway Protocol
- 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.
- RFC0889 - Internet Delay Experiments
- 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.
- RFC0890 - Exterior Gateway Protocol implementation schedule
- 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.
- RFC0891 - DCN Local-Network Protocols
- 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.
- RFC0892 - ISO Transport Protocol specification
- 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.
- RFC0893 - Trailer encapsulations
- 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.
- RFC0894 - A Standard for the Transmission of IP Datagrams over Ethernet Networks
- 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.
- RFC0895 - Standard for the transmission of IP datagrams over experimental Ethernet networks
- 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.
- RFC0896 - Congestion Control in IP/TCP Internetworks
- This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards.
- RFC0897 - Domain name system implementation schedule
- This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is a partial update of RFC 881. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The names of hosts will be changed to domain style names. Hosts will begin to use domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84. This applies to both the ARPA research hosts and the DDN operational hosts. This is an official policy statement of the ICCB and the DARPA.
- RFC0898 - Gateway special interest group meeting notes
- 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.
- RFC0899 - Request For Comments summary notes: 800-899
- RFC0900 - Assigned Numbers
- This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997.
- RFC0901 - Official ARPA-Internet protocols
- This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991.
- RFC0902 - ARPA Internet Protocol policy
- 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.
- RFC0903 - A Reverse Address Resolution Protocol
- 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.
- RFC0904 - Exterior Gateway Protocol formal specification
- 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.
- RFC0905 - ISO Transport Protocol specification ISO DP 8073
- 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.
- RFC0906 - Bootstrap loading using TFTP
- 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.
- RFC0907 - Host Access Protocol specification
- 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.
- RFC0908 - Reliable Data Protocol
- 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.
- RFC0909 - Loader Debugger Protocol
- 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.
- RFC0910 - Multimedia mail meeting notes
- 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.
- RFC0911 - EGP Gateway under Berkeley UNIX 4.2
- 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).
- RFC0912 - Authentication service
- This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server.
- RFC0913 - Simple File Transfer Protocol
- 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.
- RFC0914 - Thinwire protocol for connecting personal computers to the Internet
- 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.
- RFC0915 - Network mail path service
- 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.
- RFC0916 - Reliable Asynchronous Transfer Protocol (RATP)
- 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.
- RFC0917 - Internet subnets
- 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.
- RFC0918 - Post Office Protocol
- This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP.
- RFC0919 - Broadcasting Internet Datagrams
- 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.
- RFC0920 - Domain requirements
- 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.
- RFC0921 - Domain name system implementation schedule - revised
- 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.
- RFC0922 - Broadcasting Internet datagrams in the presence of subnets
- 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.
- RFC0923 - Assigned numbers
- This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997.
- RFC0924 - Official ARPA-Internet protocols for connecting personal computers to the Internet
- This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.
- RFC0925 - Multi-LAN address resolution
- 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.
- RFC0926 - Protocol for providing the connectionless mode network services
- 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.
- RFC0927 - TACACS user identification Telnet option
- 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.
- RFC0928 - Introduction to proposed DoD standard H-FP
- 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.
- RFC0929 - Proposed Host-Front End Protocol
- 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.
- RFC0930 - Telnet terminal type option
- This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation.
- RFC0931 - Authentication server
- This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned.
- RFC0932 - Subnetwork addressing scheme
- 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.
- RFC0933 - Output marking Telnet option
- 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.
- RFC0934 - Proposed standard for message encapsulation
- 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.
- RFC0935 - Reliable link layer protocols
- 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.
- RFC0936 - Another Internet subnet addressing scheme
- 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.
- RFC0937 - Post Office Protocol: Version 2
- 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.
- RFC0938 - Internet Reliable Transaction Protocol functional and interface specification
- 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.
- RFC0939 - Executive summary of the NRC report on transport protocols for Department of Defense data networks
- 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.
- RFC0940 - Toward an Internet standard scheme for subnetting
- 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.
- RFC0941 - Addendum to the network service definition covering network layer addressing
- 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.
- RFC0942 - Transport protocols for Department of Defense data networks
- 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).
- RFC0943 - Assigned numbers
- This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.
- RFC0944 - Official ARPA-Internet protocols
- This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.
- RFC0945 - DoD statement on the NRC report
- In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only.
- RFC0946 - Telnet terminal location number option
- 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.
- RFC0947 - Multi-network broadcasting within the Internet
- 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.
- RFC0948 - Two methods for the transmission of IP datagrams over IEEE 802.3 networks
- This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
- RFC0949 - FTP unique-named store command
- 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.
- RFC0950 - Internet Standard Subnetting Procedure
- 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.
- RFC0951 - Bootstrap Protocol
- This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
- RFC0952 - DoD Internet host table specification
- 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.
- RFC0953 - Hostname Server
- 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.
- RFC0954 - NICNAME/WHOIS
- This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812.
- RFC0955 - Towards a transport service for transaction processing applications
- 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.
- RFC0956 - Algorithms for synchronizing network clocks
- 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.
- RFC0957 - Experiments in network clock synchronization
- 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.
- RFC0958 - Network Time Protocol (NTP)
- This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
- RFC0959 - File Transfer Protocol
- This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition.
- RFC0960 - Assigned numbers
- This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.
- RFC0961 - Official ARPA-Internet protocols
- This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.
- RFC0962 - TCP-4 prime
- 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.
- RFC0963 - Some problems with the specification of the Military Standard Internet Protocol
- 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.
- RFC0964 - Some problems with the specification of the Military Standard Transmission Control Protocol
- 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.
- RFC0965 - Format for a graphical communication protocol
- 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.
- RFC0966 - Host groups: A multicast extension to the Internet Protocol
- 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.
- RFC0967 - All victims together
- 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.
- RFC0968 - Twas the night before start-up
- This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.
- RFC0969 - NETBLT: A bulk data transfer protocol
- 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.
- RFC0970 - On Packet Switches With Infinite Storage
- The purpose of this RFC is to focus discussion on a particular problem in the ARPA-Internet and possible methods of solution. Most prior work on congestion in datagram systems focuses on buffer management. In this memo the case of a packet switch with infinite storage is considered. 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. An unexpected result is found that shows 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, new solutions applicable to switches with finite storage may be found. No proposed solutions this document are intended as standards for the ARPA-Internet at this time.
- RFC0971 - Survey of data representation standards
- 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.
- RFC0972 - Password Generator Protocol
- 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.
- RFC0973 - Domain system changes and observations
- This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system.
- RFC0974 - Mail routing and the domain system
- This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing.
- RFC0975 - Autonomous confederations
- 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.
- RFC0976 - UUCP mail interchange format standard
- 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.
- RFC0977 - Network News Transfer Protocol
- 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.
- RFC0978 - Voice File Interchange Protocol (VFIP)
- 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.
- RFC0979 - PSN End-to-End functional specification
- 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.
- RFC0980 - Protocol document order information
- 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).
- RFC0981 - Experimental multiple-path routing algorithm
- This document introduces wiretap algorithms, a class of experimental, multiple routing algorithms that compute quasi-optimum routes for stations sharing a packet-radio broadcast channel. The primary route (a minimum-distance path), and additional paths ordered by distance, which serve as alternate routes should the primary route fail, are computed. This prototype is presented as an example of a class of routing algorithms and data-base management techniques that may find wider application in the Internet community. Discussions and suggestions for improvements are welcomed.
- RFC0982 - Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address
- 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.
- RFC0983 - ISO transport arrives on top of the TCP
- This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged.
- RFC0984 - PCMAIL: A distributed mail system for personal computers
- This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993.
- RFC0985 - Requirements for Internet gateways - draft
- 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.
- RFC0986 - Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol
- This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
- RFC0987 - Mapping between X.400 and RFC 822
- The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
- RFC0988 - Host extensions for IP multicasting
- This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here.
- RFC0989 - Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures
- This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated.
- RFC0990 - Assigned numbers
- This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900.
- RFC0991 - Official ARPA-Internet protocols
- This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924.
- RFC0992 - On communication support for fault tolerant process groups
- 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.
- RFC0993 - PCMAIL: A distributed mail system for personal computers
- This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984.
- RFC0994 - Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service
- 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).
- RFC0995 - End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473
- 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.
- RFC0996 - Statistics server
- 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.
- RFC0997 - Internet numbers
- This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900.
- RFC0998 - NETBLT: A bulk data transfer protocol
- 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.
- RFC0999 - Requests For Comments summary notes: 900-999
- RFC1000 - Request For Comments reference guide
- 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.
- RFC1001 - Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods
- 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".
- RFC1002 - Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications
- 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".
- RFC1003 - Issues in defining an equations representation standard
- 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.
- RFC1004 - Distributed-protocol authentication scheme
- 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.
- RFC1005 - ARPANET AHIP-E Host Access Protocol (enhanced AHIP)
- 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.
- RFC1006 - ISO Transport Service on top of the TCP Version: 3
- This memo specifies a standard for the Internet community. Hosts on the Internet that choose to implement ISO transport services on top of the TCP are expected to adopt and implement this standard. TCP port 102 is reserved for hosts which implement this standard. This memo specifies version 3 of the protocol and supersedes RFC-983. Changes between the protocol is described in RFC-983 and this memo are minor, but unfortunately incompatible.
- RFC1007 - Military supplement to the ISO Transport Protocol
- 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.
- RFC1008 - Implementation guide for the ISO Transport Protocol
- 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.
- RFC1009 - Requirements for Internet gateways
- This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community.
- RFC1010 - Assigned numbers
- This memo is an official status report on the numbers used in protocols in the Internet community. It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations.
- RFC1011 - Official Internet protocols
- 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.
- RFC1012 - Bibliography of Request For Comments 1 through 999
- 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.
- RFC1013 - X Window System Protocol, version 11: Alpha update April 1987
- 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.
- RFC1014 - XDR: External Data Representation standard
- 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.
- RFC1015 - Implementation plan for interagency research Internet
- 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.
- RFC1016 - Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)
- 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.
- RFC1017 - Network requirements for scientific research: Internet task force on scientific computing
- 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.
- RFC1018 - Some comments on SQuID
- 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. Distribution of this memo is unlimited.
- RFC1019 - Report of the Workshop on Environments for Computational Mathematics
- 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.
- RFC1020 - Internet numbers
- This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers. This RFC obsoletes RFC-997.
- RFC1021 - High-level Entity Management System (HEMS)
- 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.
- RFC1022 - High-level Entity Management Protocol (HEMP)
- 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.
- RFC1023 - HEMS monitoring and control language
- This RFC specifies the High-Level Entity Management System (HEMS) Monitoring and Control Language. This language defines the requests and replies used in HEMS. This memo assumes knowledge of the HEMS system described in RFC-1021, and of the ISO data encoding standard, ASN.1.
- RFC1024 - HEMS variable definitions
- 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.
- RFC1025 - TCP and IP bake off
- 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.
- RFC1026 - Addendum to RFC 987: (Mapping between X.400 and RFC-822)
- This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements.
- RFC1027 - Using ARP to implement transparent subnet gateways
- 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".
- RFC1028 - Simple Gateway Monitoring Protocol
- 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.
- RFC1029 - More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets
- 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.
- RFC1030 - On testing the NETBLT Protocol over divers networks
- 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.
- RFC1031 - MILNET name domain transition
- 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.
- RFC1032 - Domain administrators guide
- 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.
- RFC1033 - Domain Administrators Operations Guide
- 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).
- RFC1034 - Domain names - concepts and facilities
- 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.
- RFC1035 - Domain names - implementation and specification
- 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.
- RFC1036 - Standard for interchange of USENET messages
- This RFC defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is distributed as an RFC to make this information easily accessible to the Internet community. It does not specify an Internet standard.
- RFC1037 - NFILE - a file access protocol
- 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.
- RFC1038 - Draft revised IP security option
- This memo is a pre-publication draft of the revised Internet Protocol Security Option. This RFC reflects the version as approved by the Protocol Standards Steering group, and is provided for informational purposes only. The final version of this document will be available from Navy publications and should not differ from this document in any major fashion. This document will be published as a change to the MIL- STD 1777, "Internet Protocol".
- RFC1039 - DoD statement on Open Systems Interconnection protocols
- 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.
- RFC1040 - Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures
- This RFC is the Outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This memo defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated.
- RFC1041 - Telnet 3270 regime option
- 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.
- RFC1042 - Standard for the transmission of IP datagrams over IEEE 802 networks
- 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.
- RFC1043 - Telnet Data Entry Terminal option: DODIIS implementation
- 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.
- RFC1044 - Internet Protocol on Network System's HYPERchannel: Protocol Specification
- 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.
- RFC1045 - VMTP: Versatile Message Transaction Protocol: Protocol specification
- 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.
- RFC1046 - Queuing algorithm to provide type-of-service for IP links
- 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.
- RFC1047 - Duplicate messages and SMTP
- 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.
- RFC1048 - BOOTP vendor information extensions
- This memo proposes an addition to the Bootstrap Protocol (BOOTP). Comments and suggestions for improvements are sought.
- RFC1049 - Content-type header field for Internet messages
- This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements.
- RFC1050 - RPC: Remote Procedure Call Protocol specification
- This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package. This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration. It is not an Internet standard at this time.
- RFC1051 - Standard for the transmission of IP datagrams and ARP packets over ARCNET networks
- This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET. This RFC is a standard protocol for the Internet community.
- RFC1052 - IAB recommendations for the development of Internet network management standards
- 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.
- RFC1053 - Telnet X.3 PAD option
- This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.
- RFC1054 - Host extensions for IP multicasting
- This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. IP multicasting is the transmission of an IP datagram to a "host group", a set hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988.
- RFC1055 - Nonstandard for transmission of IP datagrams over serial lines: SLIP
- 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.
- RFC1056 - PCMAIL: A distributed mail system for personal computers
- 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.
- RFC1057 - RPC: Remote Procedure Call Protocol specification: Version 2
- 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.
- RFC1058 - Routing Information Protocol
- This RFC describes an existing protocol for exchanging routing information among gateways and other hosts. It is intended to be used as a basis for developing gateway software for use in the Internet community.
- RFC1059 - Network Time Protocol (version 1) specification and implementation
- This memo describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical master-slave configuration synchronizes logical clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. The NTP architectures, algorithms and protocols which have evolved over several years of implementation and refinement are described in this document. The prototype system, which has been in regular operation in the Internet for the last two years, is described in an Appendix along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even the cases of failure or disruption of clocks, time servers or nets. This is a Draft Standard for an Elective protocol.
- RFC1060 - Assigned numbers
- This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited.
- RFC1062 - Internet numbers
- This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community.
- RFC1063 - IP MTU discovery options
- 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.
- RFC1064 - Interactive Mail Access Protocol: Version 2
- This memo suggests a method for workstations to dynamically access mail from a mailbox server ("respository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested.
- RFC1065 - Structure and identification of management information for TCP/IP-based internets
- 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.
- RFC1066 - Management Information Base for network management of TCP/IP-based internets
- This RFC provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term. In particular, together with its companion memos which describe the structure of management information along with the initial network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets, and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.
- RFC1067 - Simple Network Management Protocol
- 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.
- RFC1068 - Background File Transfer Program (BFTP)
- 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.
- RFC1069 - Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol
- 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.
- RFC1070 - Use of the Internet as a subnetwork for experimentation with the OSI network layer
- 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.
- RFC1071 - Computing the Internet checksum
- This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques.
- RFC1072 - TCP extensions for long-delay paths
- This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance.
- RFC1073 - Telnet window size option
- This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server.
- RFC1074 - NSFNET backbone SPF based Interior Gateway Protocol
- This RFC is an implementation description of the standard ANSI IS-IS and ISO ES-IS routing protocols within the NSFNET backbone network.
- RFC1075 - Distance Vector Multicast Routing Protocol
- 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.
- RFC1076 - HEMS monitoring and control language
- 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.
- RFC1077 - Critical issues in high bandwidth networking
- 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.
- RFC1078 - TCP port service Multiplexer (TCPMUX)
- This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'.
- RFC1079 - Telnet terminal speed option
- 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.
- RFC1080 - Telnet remote flow control option
- This RFC specifies a standard for the Internet community. Hosts on the Internet that do remote flow control within the Telnet protocol are expected to adopt and implement this standard.
- RFC1081 - Post Office Protocol: Version 3
- This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.
- RFC1082 - Post Office Protocol: Version 3: Extended service offerings
- 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.
- RFC1083 - IAB official protocol standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). 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.
- RFC1084 - BOOTP vendor information extensions
- This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville. This memo will be updated as additional tags are are defined. This edition introduces Tag 13 for Boot File Size. Comments and suggestions for improvements are sought.
- RFC1085 - ISO presentation services on top of TCP/IP based internets
- 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.
- RFC1086 - ISO-TP0 bridge between TCP and X.25
- 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.
- RFC1087 - Ethics and the Internet
- This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet.
- RFC1088 - Standard for the transmission of IP datagrams over NetBIOS networks
- This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams on NetBIOS networks.
- RFC1089 - SNMP over Ethernet
- 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.
- RFC1090 - SMTP on X.25
- This memo proposes a standard for SMTP on the virtual circuit facility provided by the X.25 standard of the CCITT.
- RFC1091 - Telnet terminal-type option
- 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
- RFC1092 - EGP and policy based routing in the new NSFNET backbone
- 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.
- RFC1093 - NSFNET routing architecture
- 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.
- RFC1094 - NFS: Network File System Protocol specification
- 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.
- RFC1095 - Common Management Information Services and Protocol over TCP/IP (CMOT)
- This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard. Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a comprehensive architecture and system for managing TCP/IP- based internets, and in particular the Internet.
- RFC1096 - Telnet X display location option
- 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.
- RFC1097 - Telnet subliminal-message option
- 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.
- RFC1098 - Simple Network Management Protocol (SNMP)
- This RFC is a re-release of RFC 1067, with a changed "Status of this Memo" section. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet.
- RFC1099 - Request for Comments Summary: RFC Numbers 1000-1099
- RFC1100 - IAB official protocol standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). 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.
- RFC1101 - DNS encoding of network names and other types
- 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.
- RFC1102 - Policy routing in Internet protocols
- 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.
- RFC1103 - Proposed standard for the transmission of IP datagrams over FDDI Networks
- This RFC specifies a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]
- RFC1104 - Models of policy based routing
- 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.
- RFC1105 - Border Gateway Protocol (BGP)
- This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK]
- RFC1106 - TCP big window and NAK options
- This memo discusses two extensions to the TCP protocol to provide a more efficient operation over a network with a high bandwidth*delay product. The extensions described in this document have been implemented and shown to work using resources at NASA. This memo describes an Experimental Protocol, these extensions are not proposed as an Internet standard, but as a starting point for further research.
- RFC1107 - Plan for Internet directory services
- 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.
- RFC1108 - U.S. Department of Defense Security Options for the Internet Protocol
- This RFC specifies the U.S. Department of Defense Basic Security Option 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. [STANDARDS-TRACK]
- RFC1109 - Report of the second Ad Hoc Network Management Review Group
- 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.
- RFC1110 - Problem with the TCP big window option
- This memo comments on the TCP Big Window option described in RFC 1106.
- RFC1111 - Request for comments on Request for Comments: Instructions to RFC authors
- This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard.
- RFC1112 - Host extensions for IP multicasting
- This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]
- RFC1113 - Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures
- This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK]
- RFC1114 - Privacy enhancement for Internet electronic mail: Part II - certificate-based key management
- This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK]
- RFC1115 - Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers
- This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK]
- RFC1116 - Telnet Linemode option
- Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK]
- RFC1117 - Internet numbers
- This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community.
- RFC1118 - Hitchhikers guide to the Internet
- 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.
- RFC1119 - Network Time Protocol (version 2) specification and implementation
- This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. [STANDARDS-TRACK]
- RFC1120 - Internet Activities Board
- This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard.
- RFC1121 - Act one - the poems
- 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.
- RFC1122 - Requirements for Internet Hosts - Communication Layers
- This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]
- RFC1123 - Requirements for Internet Hosts - Application and Support
- This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]
- RFC1124 - Policy issues in interconnecting networks
- 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.
- RFC1125 - Policy requirements for inter Administrative Domain routing
- 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.
- RFC1126 - Goals and functional requirements for inter-autonomous system routing
- 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.
- RFC1127 - Perspective on the Host Requirements RFCs
- This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol.
- RFC1128 - Measured performance of the Network Time Protocol in the Internet system
- 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.
- RFC1129 - Internet Time Synchronization: The Network Time Protocol
- 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.
- RFC1130 - IAB official protocol standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).
- RFC1131 - OSPF specification
- This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK]
- RFC1132 - Standard for the transmission of 802.2 packets over IPX networks
- 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.
- RFC1133 - Routing between the NSFNET and the DDN
- 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.
- RFC1134 - Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links
- This proposal 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 Point-to-Point Protocol Working Group chair by January 15, 1990. Comments will be reviewed at the February 1990 IETF meeting, with the goal of advancing PPP to draft standard status. [STANDARDS-TRACK]
- RFC1135 - Helminthiasis of the Internet
- 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.
- RFC1136 - Administrative Domains and Routing Domains: A model for routing in the Internet
- 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.
- RFC1137 - Mapping between full RFC 822 and RFC 822 with restricted encoding
- 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.
- RFC1138 - Mapping between X.400(1988) / ISO 10021 and RFC 822
- Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026.
- RFC1140 - IAB official protocol standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo 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.
- RFC1141 - Incremental updating of the Internet checksum
- 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.
- RFC1142 - OSI IS-IS Intra-domain Routing Protocol
- This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard.
- RFC1143 - The Q Method of Implementing TELNET Option Negotiation
- 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.
- RFC1144 - Compressing TCP/IP Headers for Low-Speed Serial Links
- 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]
- RFC1145 - TCP alternate checksum options
- This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use.
- RFC1146 - TCP alternate checksum options
- This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. Note: This RFC corrects errors introduced in the editing process in RFC 1145.
- RFC1148 - Mapping between X.400(1988) / ISO 10021 and RFC 822
- This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing.
- RFC1149 - Standard for the transmission of IP datagrams on avian carriers
- 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.
- RFC1150 - FYI on FYI: Introduction to the FYI Notes
- This memo is the first in a new sub-series of RFCs called FYIs (For Your Information). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 1.]
- RFC1151 - Version 2 of the Reliable Data Protocol (RDP)
- 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.
- RFC1152 - Workshop report: Internet research steering group workshop on very-high-speed networks
- 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.
- RFC1153 - Digest message format
- This memo describes the de facto standard Digest Message Format. This is an elective experimental protocol.
- RFC1154 - Encoding header field for internet messages
- This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement).
- RFC1155 - Structure and identification of management information for TCP/IP-based internets
- 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]
- RFC1156 - Management Information Base for network management of TCP/IP-based internets
- 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]
- RFC1157 - Simple Network Management Protocol (SNMP)
- 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]
- RFC1158 - Management Information Base for network management of TCP/IP-based internets: MIB-II
- This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK]
- RFC1159 - Message Send Protocol
- This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol.
- RFC1160 - Internet Activities Board
- This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. This is a revision of RFC 1120.
- RFC1161 - SNMP over OSI
- This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community,
- RFC1165 - Network Time Protocol (NTP) over the OSI Remote Operations Service
- 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.
- RFC1166 - Internet numbers
- This memo is a status report on the network numbers and autonomous system numbers used in the Internet community.
- RFC1167 - Thoughts on the National Research and Education Network
- 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.
- RFC1168 - Intermail and Commercial Mail Relay services
- 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.
- RFC1169 - Explaining the role of GOSIP
- 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.
- RFC1170 - Public key standards and licenses
- 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.
- RFC1173 - Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet
- 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.
- RFC1174 - IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status
- 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.
- RFC1176 - Interactive Mail Access Protocol: Version 2
- 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.
- RFC1177 - FYI on Questions and Answers: Answers to commonly asked "new internet user" questions
- 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.]
- RFC1178 - Choosing a name for your computer
- This FYI RFC is a republication of a Communications of the ACM article on guidelines on what to do and what not to do when naming your computer. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 5.]
- RFC1179 - Line printer daemon protocol
- 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.
- RFC1180 - TCP/IP tutorial
- 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.
- RFC1181 - RIPE Terms of Reference
- 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.
- RFC1183 - New DNS RR Definitions
- This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements.
- RFC1185 - TCP Extension for High-Speed Paths
- 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.
- RFC1186 - MD4 Message Digest Algorithm
- This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard.
- RFC1187 - Bulk Table Retrieval with the SNMP
- 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.
- RFC1191 - Path MTU discovery
- 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. [STANDARDS-TRACK]
- RFC1192 - Commercialization of the Internet summary report
- 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.
- RFC1193 - Client requirements for real-time communication services
- This memo describes client requirements for real-time communication services. This memo provides information for the Internet community, and requests discussion and suggestions for improvements. It does not specify any standard.
- RFC1194 - Finger User Information Protocol
- This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. [STANDARDS-TRACK]
- RFC1195 - Use of OSI IS-IS for routing in TCP/IP and dual environments
- This memo specifies an integrated routing protocol, based on the OSI Intra-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 Task Force. [STANDARDS-TRACK]
- RFC1196 - Finger User Information Protocol
- This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194. [STANDARDS-TRACK]
- RFC1197 - Using ODA for translating multimedia information
- 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.
- RFC1198 - FYI on the X window system
- 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.
- RFC1199 - Request for Comments Summary Notes: 1100-1199
- RFC1200 - IAB official protocol standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). 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.
- RFC1201 - Transmitting IP traffic over ARCNET networks
- 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]
- RFC1202 - Directory Assistance service
- 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.
- RFC1203 - Interactive Mail Access Protocol: Version 3
- 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.
- RFC1204 - Message Posting Protocol (MPP)
- 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.
- RFC1205 - 5250 Telnet interface
- 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.
- RFC1206 - FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions
- This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4]
- RFC1207 - FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions
- This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the 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.
- RFC1208 - A Glossary of Networking Terms
- 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.
- RFC1210 - Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990
- This report complements a shorter printed version which appeared in a summary report of all the committees which met in Brussels and Washington last July, 1990. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1211 - Problems with the maintenance of large mailing lists
- 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.
- RFC1216 - Gigabit network economics and paradigm shifts
- This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]
- RFC1217 - Memo from the Consortium for Slow Commotion Research (CSCR)
- 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.
- RFC1218 - Naming scheme for c=US
- This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1219 - On the assignment of subnet numbers
- 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.
- RFC1221 - Host Access Protocol (HAP) specification: Version 2
- 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.
- RFC1222 - Advancing the NSFNET routing architecture
- 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.
- RFC1223 - OSI CLNS and LLC1 protocols on Network Systems HYPERchannel
- 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.
- RFC1225 - Post Office Protocol: Version 3
- This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK]
- RFC1226 - Internet protocol encapsulation of AX.25 frames
- 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.
- RFC1227 - SNMP MUX protocol and MIB
- 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.
- RFC1228 - SNMP-DPI: Simple Network Management Protocol Distributed Program Interface
- This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.
- RFC1234 - Tunneling IPX traffic through IP networks
- 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]
- RFC1235 - Coherent File Distribution Protocol
- 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.
- RFC1236 - IP to X.121 address mapping for DDN
- 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.
- RFC1238 - CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542)
- 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.
- RFC1239 - Reassignment of experimental MIBs to standard MIBs
- This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK]
- RFC1240 - OSI connectionless transport services on top of UDP: Version 1
- This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK]
- RFC1241 - Scheme for an internet encapsulation protocol: Version 1
- This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.
- RFC1244 - Site Security Handbook
- 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]
- RFC1248 - OSPF Version 2 Management Information Base
- This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]
- RFC1249 - DIXIE Protocol Specification
- 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.
- RFC1250 - IAB Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1251 - Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members
- This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9]
- RFC1253 - OSPF Version 2 Management Information Base
- This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]
- RFC1255 - A Naming Scheme for c=US
- This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1257 - Isochronous applications do not require jitter-controlled networks
- This memo argues that jitter control is not required for networks to support isochronous applications. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1258 - BSD Rlogin
- The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1259 - Building the open road: The NREN as test-bed for the national public network
- This memo discusses the background and importance of NREN. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1261 - Transition of Nic Services
- This memo outlines the transition of NIC Services. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1262 - Guidelines for Internet Measurement Activities
- 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.
- RFC1263 - TCP Extensions Considered Harmful
- 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 the Internet protocol suite. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1270 - SNMP Communications Services
- 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.
- RFC1273 - Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations
- This memo describes plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1280 - IAB Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1282 - BSD Rlogin
- 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.
- RFC1287 - Towards the Future Internet Architecture
- 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.
- RFC1288 - The Finger User Information Protocol
- This memo describes the Finger user information protocol.This is a simple protocol which provides an interface to a remote user information program. [STANDARDS-TRACK]
- RFC1290 - There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places
- 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. This RFC provides information for the Internet community. It does not specify an Internet standard.
- RFC1291 - Mid-Level Networks Potential Technical Services
- 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. This RFC provides information for the Internet community. It does not specify an Internet standard.
- RFC1295 - User Bill of Rights for entries and listings in the Public Directory
- 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) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 and RFC1407. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1296 - Internet Growth (1981-1991)
- This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]
- RFC1299 - Summary of 1200-1299
- RFC1300 - Remembrances of Things Past
- Poem. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1301 - Multicast Transport Protocol
- 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.
- RFC1303 - A Convention for Describing SNMP-based Agents
- This memo suggests a straight-forward approach towards describing SNMP- based agents. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1305 - Network Time Protocol (Version 3) Specification, Implementation and Analysis
- This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK]
- RFC1306 - Experiences Supporting By-Request Circuit-Switched T3 Networks
- This memo describes the experiences of a project team at Cray Research, 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. This RFC provides information for the Internet community. It does not specify an Internet standard.
- RFC1307 - Dynamically Switched Link Control Protocol
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC1310 - The Internet Standards Process
- This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]
- RFC1311 - Introduction to the STD Notes
- 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]
- RFC1312 - Message Send Protocol 2
- 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.
- RFC1313 - Today's Programming for KRFC AM 1313 Internet Talk Radio
- 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.
- RFC1324 - A Discussion on Computer Network Conferencing
- 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. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1325 - FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions
- This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the 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 an Internet standard.
- RFC1326 - Mutual Encapsulation Considered Dangerous
- This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A). This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1327 - Mapping between X.400(1988) / ISO 10021 and RFC 822
- This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. [STANDARDS-TRACK]
- RFC1328 - X.400 1988 to 1984 downgrading
- This document considers issues of downgrading from X.400(1988) to X.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. [STANDARDS-TRACK]
- RFC1329 - Thoughts on Address Resolution for Dual MAC FDDI Networks
- 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.
- RFC1330 - Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community
- 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.
- RFC1335 - A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion
- This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for the Internet. This is an "idea" paper and discussion is strongly encouraged. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1336 - Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members
- This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify any standard.
- RFC1337 - TIME-WAIT Assassination Hazards in TCP
- This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1338 - Supernetting: an Address Assignment and Aggregation Strategy
- This memo discusses strategies for address assignment of the existing IP 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. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1339 - Remote Mail Checking Protocol
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC1340 - Assigned Numbers
- This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.
- RFC1343 - A User Agent Configuration Mechanism for Multimedia Mail Format Information
- 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.
- RFC1344 - Implications of MIME for Internet Mail Gateways
- 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.
- RFC1346 - Resource Allocation, Control, and Accounting for the Use of Network Resources
- 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.
- RFC1347 - TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing
- 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.
- RFC1348 - DNS NSAP RRs
- This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community.
- RFC1350 - The TFTP Protocol (Revision 2)
- TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK]
- RFC1357 - A Format for E-mailing Bibliographic Records
- This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR). This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1358 - Charter of the Internet Architecture Board (IAB)
- The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1359 - Connecting to the Internet - What Connecting Institutions Should Anticipate
- This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1360 - IAB Official Protocol Standards
- RFC1361 - Simple Network Time Protocol (SNTP)
- This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memorandum does not obsolete or update any RFC. This memo provides information for the Internet community. It does not specify an Internet standard. Discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.9 contain the lists of protocols in each stage of standardization. Finally come pointers to references and contacts for further information. [STANDARDS-TRACK]
- RFC1362 - Novell IPX over Various WAN Media (IPXWAN)
- This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1363 - A Proposed Flow Specification
- RFC1365 - An IP Address Extension Proposal
- RFC1366 - Guidelines for Management of IP Address Space
- This document has been reviewed by the Federal Engineering Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines the various criteria to be used when designing Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK] 1363 Partridge Spt 92 A Proposed Flow Specification 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). This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1367 - Schedule for IP Address Space Management Guidelines
- This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1370 - Applicability Statement for OSPF
- 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]
- RFC1373 - Portable DUAs
- 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.
- RFC1374 - IP and ARP on HIPPI
- The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. 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. This memo is intended to become an Internet Standard. [STANDARDS-TRACK]
- RFC1375 - Suggestion for New Classes of IP Addresses
- 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. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1379 - Extending TCP for Transactions -- Concepts
- This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1383 - An Experiment in DNS Based IP Routing
- Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community.
- RFC1385 - EIP: The Extended Internet Protocol
- EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1386 - The US Domain
- 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.
- RFC1391 - The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force
- 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 memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1393 - Traceroute Using an IP Option
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC1394 - Relationship of Telex Answerback Codes to Internet Domains
- 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 memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1395 - BOOTP Vendor Information Extensions
- This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP).
- RFC1396 - The Process for Organization of Internet Standards Working Group (POISED)
- 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. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1399 - Summary of 1300-1399
- RFC1400 - Transition and Modernization of the Internet Registration Service
- 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.
- RFC1401 - Correspondence between the IAB and DISA on the use of DNS
- This memo reproduces three letters exchanged between the Internet Activities 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". This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1402 - There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places
- 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. This RFC provides information for the Internet community. It does not specify an Internet standard.
- RFC1403 - BGP OSPF Interaction
- This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]
- RFC1410 - IAB Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).
- RFC1415 - FTP-FTAM Gateway Specification
- 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. [STANDARDS-TRACK]
- RFC1416 - Telnet Authentication Option
- This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community.
- RFC1417 - NADF Standing Documents: A Brief Overview
- The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1429 - Listserv Distribute Protocol
- This memo specifies a subset of the distribution protocol used by the BITNET LISTSERV to deliver mail messages to large amounts of recipients. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1432 - Recent Internet Books
- Here is a list of books related to using the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1434 - Data Link Switching: Switch-to-Switch Protocol
- This RFC describes IBM's support of Data Link Switching over TCP/IP. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1436 - The Internet Gopher Protocol (a distributed document search and retrieval protocol)
- 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 memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1437 - The Extension of MIME Content-Types to a New Medium
- This document defines one particular type of MIME data, the matter- transport/sentient-life-form type. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1438 - Internet Engineering Task Force Statements Of Boredom (SOBs)
- 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.
- RFC1439 - The Uniqueness of Unique Identifiers
- This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1440 - SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
- 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.
- RFC1453 - A Comment on Packet Video Remote Conferencing and the Transport/Network Layers
- This RFC is a vehicle to inform the Internet community about XTP as it benefits from past Internet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1454 - Comparison of Proposals for Next Version of IP
- This is a slightly edited reprint of RARE Technical Report (RTC(93)004). This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1455 - Physical Link Security Type of Service
- This RFC documents an experimental protocol providing a Type of Service (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite. This memo defines an Experimental Protocol for the Internet community.
- RFC1456 - Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification
- This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into 7-bit US ASCII and in an 8-bit form. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1457 - Security Label Framework for the Internet
- 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.
- RFC1458 - Requirements for Multicast Protocols
- 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.
- RFC1459 - Internet Relay Chat Protocol
- The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. This memo defines an Experimental Protocol for the Internet community.
- RFC1460 - Post Office Protocol - Version 3
- This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS-TRACK]
- RFC1464 - Using the Domain Name System To Store Arbitrary String Attributes
- This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. This memo defines an Experimental Protocol for the Internet community.
- RFC1466 - Guidelines for Management of IP Address Space
- This document proposes a plan which will forward the implementation of RFC 1174 and which defines the allocation and assignment of the network number space. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1467 - Status of CIDR Deployment in the Internet
- 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. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1469 - IP Multicast over Token-Ring Local Area Networks
- This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. [STANDARDS-TRACK]
- RFC1480 - The US Domain
- 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.
- RFC1481 - IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling
- 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.
- RFC1486 - An Experiment in Remote Printing
- This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.
- RFC1489 - Registration of a Cyrillic Character Set
- 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.
- RFC1492 - An Access Control Protocol, Sometimes Called TACACS
- 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.
- RFC1497 - BOOTP Vendor Information Extensions
- This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP).
- RFC1498 - On the Naming and Binding of Network Destinations
- 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. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1499 - Summary of 1400-1499
- RFC1500 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]
- RFC1501 - OS/2 User Group
- 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.
- RFC1503 - Algorithms for Automating Administration in SNMPv2 Managers
- 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.
- RFC1504 - Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing
- 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.
- RFC1505 - Encoding Header Field for Internet Messages
- This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.
- RFC1506 - A Tutorial on Gatewaying between X.400 and Internet Mail
- 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.
- RFC1511 - Common Authentication Technology Overview
- This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1518 - An Architecture for IP Address Allocation with CIDR
- 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]
- RFC1519 - Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy
- This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. [STANDARDS-TRACK]
- RFC1520 - Exchanging Routing Information Across Provider Boundaries in the CIDR Environment
- 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.
- RFC1524 - A User Agent Configuration Mechanism For Multimedia Mail Format Information
- 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.
- RFC1527 - What Should We Plan Given the Dilemma of the Network?
- 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 for Congress to make? This memo is a shortened version of the suggested policy draft. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1528 - Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures
- This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.
- RFC1529 - Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies
- 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.
- RFC1530 - Principles of Operation for the TPC.INT Subdomain: General Principles and Policy
- 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. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1535 - A Security Problem and Proposed Correction With Widely Deployed DNS Software
- 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. This document points out the flaw, a case in point, and a solution. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1538 - Advanced SNA/IP : A Simple SNA Transport Protocol
- This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1539 - The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force
- The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]
- RFC1540 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]
- RFC1541 - Dynamic Host Configuration Protocol
- The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]
- RFC1542 - Clarifications and Extensions for the Bootstrap Protocol
- Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called "BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]
- RFC1543 - Instructions to RFC Authors
- This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1545 - FTP Operation Over Big Address Records (FOOBAR)
- This RFC specifies a method for assigning long addresses in the HOST- PORT specification for the data port to be used in establishing a data connection for File Transfer Protocol, FTP (STD 9, RFC 959). This is a general solution, applicable for all "next generation" IP alternatives, and can also be extended to allow FTP operation over transport interfaces other than TCP. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1546 - Host Anycasting Service
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1550 - IP: Next Generation (IPng) White Paper Solicitation
- 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.
- RFC1551 - Novell IPX Over Various WAN Media (IPXWAN)
- This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1554 - ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP
- 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.
- RFC1555 - Hebrew Character Encoding for Internet Messages
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1556 - Handling of Bi-directional Texts in MIME
- This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1557 - Korean Character Encoding for Internet Messages
- 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.
- RFC1558 - A String Representation of LDAP Search Filters
- The Lightweight Directory Access Protocol (LDAP) 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1560 - The MultiProtocol Internet
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1562 - Naming Guidelines for the AARNet X.500 Directory Service
- This document is an AARNet (Australian Academic and Research Network) Engineering Note (AEN-001). AARNet Engineering Notes are engineering documents of the AARNet Engineering Working Group, and record current or proposed operational practices related to the provision of Internetworking services within Australia, and AARNet in particular. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1563 - The text/enriched MIME Content-type
- MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1568 - Simple Network Paging Protocol - Version 1(b)
- This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1569 - Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures
- This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1579 - Firewall-Friendly FTP
- This memo describes a suggested change to the behavior of FTP client programs. This document provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1580 - Guide to Network Resource Tools
- 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]
- RFC1581 - Protocol Analysis for Extensions to RIP to Support Demand Circuits
- As required by Routing Protocol Criteria, this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIP and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1582 - Extensions to RIP to Support Demand Circuits
- This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]
- RFC1583 - OSPF Version 2
- This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]
- RFC1584 - Multicast Extensions to OSPF
- This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. [STANDARDS-TRACK]
- RFC1585 - MOSPF: Analysis and Experience
- This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering Task Force internet routing protocol standardization criteria" ([RFC 1264]). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1588 - White Pages Meeting Report
- 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.
- RFC1589 - A Kernel Model for Precision Timekeeping
- 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.
- RFC1590 - Media Type Registration Procedure
- 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 Media Types to make it appropriate to use the same registrations and specifications with other applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1591 - Domain Name System Structure and Delegation
- 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.
- RFC1592 - Simple Network Management Protocol Distributed Protocol Interface Version 2.0
- 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.
- RFC1593 - SNA APPN Node MIB
- This RFC describes IBM's SNMP support for SNA Advanced Peer-to-Peer Networking (APPN) nodes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1597 - Address Allocation for Private Internets
- 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.
- RFC1599 - Summary of 1500-1599
- RFC1600 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
- RFC1601 - Charter of the Internet Architecture Board (IAB)
- This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1602 - The Internet Standards Process -- Revision 2
- This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1604 - Definitions of Managed Objects for Frame Relay Service
- This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]
- RFC1605 - SONET to Sonnet Translation
- 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). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1606 - A Historical Perspective On The Usage Of IP Version 9
- This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1607 - A VIEW FROM THE 21ST CENTURY
- 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.
- RFC1610 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
- RFC1613 - cisco Systems X.25 over TCP (XOT)
- 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.
- RFC1615 - Migrating from X.400(84) to X.400(88)
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1616 - X.400(1988) for the Academic and Research Community in Europe
- 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.
- RFC1617 - Naming and Structuring Guidelines for X.500 Directory Pilots
- This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1620 - Internet Architecture Extensions for Shared Media
- This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1624 - Computation of the Internet Checksum via Incremental Update
- This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1627 - Network 10 Considered Harmful (Some Practices Shouldn't be Codified)
- 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.
- RFC1630 - 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
- 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.
- RFC1631 - The IP Network Address Translator (NAT)
- This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1633 - Integrated Services in the Internet Architecture: an Overview
- 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 memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1634 - Novell IPX Over Various WAN Media (IPXWAN)
- This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1636 - Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994
- 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 memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1637 - DNS NSAP Resource Records
- This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. This memo defines an Experimental Protocol for the Internet community.
- RFC1639 - FTP Operation Over Big Address Records (FOOBAR)
- This RFC specifies a method for assigning addresses other than 32-bit IPv4 addresses to data ports through the specification of a "long Port (LPRT)" command and "Long Passive (LPSV)" reply, each having as its argument a <long-host-port>, which allows for additional address families, variable length network addresses and variable length port numbers. This memo defines an Experimental Protocol for the Internet community.
- RFC1640 - The Process for Organization of Internet Standards Working Group (POISED)
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1641 - Using Unicode with MIME
- This document specifies the usage of Unicode within MIME. This memo defines an Experimental Protocol for the Internet community.
- RFC1642 - UTF-7 - A Mail-Safe Transformation Format of Unicode
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC1643 - Definitions of Managed Objects for the Ethernet-like Interface Types
- This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]
- RFC1644 - T/TCP -- TCP Extensions for Transactions Functional Specification
- This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This memo describes an Experimental Protocol for the Internet community.
- RFC1645 - Simple Network Paging Protocol - Version 2
- This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1651 - SMTP Service Extensions
- This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]
- RFC1652 - SMTP Service Extension for 8bit-MIMEtransport
- 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. [STANDARDS-TRACK]
- RFC1666 - Definitions of Managed Objects for SNA NAUs using SMIv2
- This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]
- RFC1667 - Modeling and Simulation Requirements for IPng
- This white paper summarizes the Distributed Interactive Simulation environment that is under development, with regard to its real-time nature, scope and magnitude of networking requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1668 - Unified Routing Requirements for IPng
- The document provides requirements on the IPng from the perspective of the Unified Routing Architecture, as described in RFC 1322. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1669 - Market Viability as a IPng Criteria
- "Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1670 - Input to IPng Engineering Considerations
- This white paper expresses some personal opinions on IPng engineering considerations, based on experience with DECnet Phase V transition. It suggests breaking down the IPng decisions and transition tasks into smaller parts so they can be tackled early by the relevant experts. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1671 - IPng White Paper on Transition and Other Considerations
- This white paper outlines some general requirements for IPng in selected areas. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1672 - Accounting Requirements for IPng
- This white paper discusses accounting requirements for IPng. It recommends that all IPng packets carry accounting tags, which would vary in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1673 - Electric Power Research Institute Comments on IPng
- This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1674 - A Cellular Industry View of IPng
- This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1675 - Security Concerns for IPng
- A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective. While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1676 - INFN Requirements for an IPng
- With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1677 - Tactical Radio Frequency Communication Requirements for IPng
- This paper describes requirements for Internet Protocol next generation (IPng) candidates with respect to their application to military tactical radio frequency (RF) communication networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1678 - IPng Requirements of Large Corporate Networks
- This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1679 - HPN Working Group Input to the IPng Requirements Solicitation
- The purpose of this document is to provide what the HPN working group perceives as requirements for an IPng protocol set. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1680 - IPng Support for ATM Services
- This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1681 - On Many Addresses per Host
- This document was submitted to the IETF IPng area in response to RFC 1550.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1682 - IPng BSD Host Implementation Analysis
- This IPng white paper, IPng BSD Host Implementation Analysis, was submitted to the IPng Directorate to provide a BSD host point of reference to assist with the engineering considerations during the IETF process to select an IPng proposal. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1683 - Multiprotocol Interoperability In IPng
- In this document, we identify several features that affect a protocol's ability to operate in a multiprotocol environment and propose the incorporation of these features into IPng. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1684 - Introduction to White Pages Services based on X.500
- 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 White Pages Service. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1685 - Writing X.400 O/R Names
- 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.
- RFC1686 - IPng Requirements: A Cable Television Industry Viewpoint
- This paper provides comments on topics related to the IPng requirements and selection criteria from a cable television industry viewpoint. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1687 - A Large Corporate User's View of IPng
- The goal of this paper is to examine the implications of IPng from the point of view of Fortune 100 corporations which have heavily invested in TCP/IP technology in order to achieve their (non-computer related) business goals.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1688 - IPng Mobility Considerations
- This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1690 - Introducing the Internet Engineering and Planning Group (IEPG)
- This memo introduces the IEPG to the Internet Community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1691 - The Document Architecture for the Cornell Digital Library
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1692 - Transport Multiplexing Protocol (TMux)
- 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.
- RFC1693 - An Extension to TCP : Partial Order Service
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC1699 - Summary of 1600-1699
- RFC1700 - Assigned Numbers
- This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.
- RFC1701 - Generic Routing Encapsulation (GRE)
- This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1702 - Generic Routing Encapsulation over IPv4 networks
- 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.
- RFC1703 - Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures
- This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1704 - On Internet Authentication
- 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.
- RFC1705 - Six Virtual Inches to the Left: The Problem with IPng
- This document was submitted to the IETF IPng area in response to RFC 1550. This RFC suggests that a new version of TCP (TCPng), and UDP, be developed and deployed. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1706 - DNS NSAP Resource Records
- 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 any NSAP address format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1707 - CATNIP: Common Architecture for the Internet
- This document was submitted to the IETF IPng area in response to RFC 1550. This paper describes a common architecture for the network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1708 - NTP PICS PROFORMA - For the Network Time Protocol Version 3
- This RFC describes a PICS Proforma translated into an Internet acceptable form. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1711 - Classifications in E-mail Routing
- This paper presents a classification for e-mail routing issues. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1712 - DNS Encoding of Geographical Location
- 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 memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1713 - Tools for DNS debugging
- Although widely used (and most of the times unnoticed), DNS (Domain Name 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1714 - Referral Whois Protocol (RWhois)
- This memo describes version 1.0 of the client/server interaction of RWhois. RWhois provides a distributed system for the display of hierarchical information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1715 - The H Ratio for Address Assignment Efficiency
- This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1717 - The PPP Multilink Protocol (MP)
- This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]
- RFC1718 - The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force
- The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]
- RFC1719 - A Direction for IPng
- This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1720 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
- RFC1725 - Post Office Protocol - Version 3
- This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK]
- RFC1726 - Technical Criteria for Choosing IP The Next Generation (IPng)
- This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1734 - POP3 AUTHentication command
- This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]
- RFC1736 - Functional Recommendations for Internet Resource Locators
- 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.
- RFC1737 - Functional Requirements for Uniform Resource Names
- 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.
- RFC1738 - Uniform Resource Locators (URL)
- This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK]
- RFC1739 - A Primer On Internet and TCP/IP Tools
- 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.
- RFC1740 - MIME Encapsulation of Macintosh Files - MacMIME
- This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. [STANDARDS-TRACK]
- RFC1741 - MIME Content Type for BinHex Encoded Files
- This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1744 - Observations on the Management of the Internet Address Space
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1748 - IEEE 802.5 MIB using SMIv2
- This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]
- RFC1750 - Randomness Recommendations for Security
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1751 - A Convention for Human-Readable 128-bit Keys
- 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.
- RFC1752 - The Recommendation for the IP Next Generation Protocol
- This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. [STANDARDS-TRACK]
- RFC1753 - IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1754 - IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1
- 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.
- RFC1756 - Remote Write Protocol - Version 1.0
- 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.
- RFC1758 - NADF Standing Documents: A Brief Overview
- The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1760 - The S/KEY One-Time Password System
- This document describes the S/KEY* One-Time Password system as released for public use by Bellcore. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1761 - Snoop Version 2 Packet Capture File Format
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1769 - Simple Network Time Protocol (SNTP)
- This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1770 - IPv4 Option for Sender Directed Multi-Destination Delivery
- This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed Broadcast Mode (SDBM). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1771 - A Border Gateway Protocol 4 (BGP-4)
- This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]
- RFC1775 - To Be "On" the Internet
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1776 - The Address is the Message
- 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.
- RFC1780 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
- RFC1786 - Representation of IP Routing Policies in a Routing Registry (ripe-81++)
- This document is an update to the original `ripe-81' proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc. 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1787 - Routing in a Multi-provider Internet
- This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1788 - ICMP Domain Name Messages
- This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.
- RFC1789 - INETPhone: Telephone Services and Servers on Internet
- This RFC presents a true telephone service, called INETPhone, which supports voice communication through the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC1790 - An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols
- 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.
- RFC1791 - TCP And UDP Over IPX Networks With Fixed Path MTU
- 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.
- RFC1792 - TCP/IPX Connection Mib Specification
- 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.
- RFC1795 - Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1
- This RFC describes use of Data Link Switching over TCP/IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1796 - Not All RFCs are Standards
- This document discusses the relationship of the Request for Comments (RFCs) notes to Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1797 - Class A Subnet Experiment
- 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.
- RFC1799 - Request for Comments Summary RFC Numbers 1700-1799
- RFC1800 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
- RFC1805 - Location-Independent Data/Software Integrity Protocol
- This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1806 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header
- This memo provides a mechanism whereby messages conforming to the [RFC 1521] ("MIME") specification can convey presentational information. This memo defines an Experimental Protocol for the Internet community.
- RFC1807 - A Format for Bibliographic Records
- This RFC defines a format for bibliographic records describing technical reports. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1808 - Relative Uniform Resource Locators
- 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 Uniform Resource Locators. [STANDARDS-TRACK]
- RFC1809 - Using the Flow Label Field in IPv6
- 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 provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1810 - Report on MD5 Performance
- This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1811 - U.S. Government Internet Domain Names
- This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1813 - NFS Version 3 Protocol Specification
- This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1814 - Unique Addresses are Good
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1815 - Character Sets ISO-10646 and ISO-10646-J-1
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1816 - U.S. Government Internet Domain Names
- This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1817 - CIDR and Classful Routing
- This document represents the IAB's (Internet Architecture Board) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1818 - Best Current Practices
- 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 Steering Group (IESG).
- RFC1820 - Multimedia E-mail (MIME) User Agent Checklist
- This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1821 - Integration of Real-time Services in an IP-ATM Network Architecture
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1822 - A Grant of Rights to Use a Specific IBM patent with Photuris
- 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.
- RFC1823 - The LDAP Application Program Interface
- 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.
- RFC1824 - The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4)
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1841 - PPP Network Control Protocol for LAN Extension
- RFC1842 - ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages
- This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. 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 informational RFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1843 - HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters
- The content of this memo is identical to an article of the same title written by the author on September 4, 1989. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1849 - "Son of 1036": News Article Format and Transmission
- By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed 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. This document defines a Historic Document for the Internet community.
- RFC1851 - The ESP Triple DES Transform
- RFC1852 - IP Authentication using Keyed SHA
- RFC1853 - IP in IP Tunneling
- This document discusses implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols. This memo provides information for the Internet community. It does not specify an Internet standard. This document describes the use of keyed SHA with the IP Authentication Header. This document defines an Experimental Protocol for the Internet community. This document describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP). This document defines an Experimental Protocol for the Internet community.
- RFC1858 - Security Considerations for IP Fragment Filtering
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1859 - ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension
- 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.
- RFC1860 - Variable Length Subnet Table For IPv4
- This document itemizes the potential values for IPv4 subnets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1861 - Simple Network Paging Protocol - Version 3 -Two-Way Enhanced
- This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1862 - Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1864 - The Content-MD5 Header Field
- This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. [STANDARDS-TRACK]
- RFC1868 - ARP Extension - UNARP
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC1871 - Addendum to RFC 1602 -- Variance Procedure
- This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC1875 - UNINETT PCA Policy Statements
- 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.
- RFC1876 - A Means for Expressing Location Information in the Domain Name System
- 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.
- RFC1877 - PPP Internet Protocol Control Protocol Extensions for Name Server Addresses
- This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server (NBNS) [4] addresses. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1878 - Variable Length Subnet Table For IPv4
- This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1879 - Class A Subnet Experiment Results and Recommendations
- 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.
- RFC1880 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
- RFC1881 - IPv6 Address Allocation Management
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1882 - The 12-Days of Technology Before Christmas
- This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1895 - The Application/CALS-1840 Content-type
- This memorandum provides guidelines for using the United States Department of Defense Military Standard MIL-STD-1840, "Automated Interchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1896 - The text/enriched MIME Content-type
- This document defines one particular type of MIME data, the text/enriched MIME type. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1898 - CyberCash Credit Card Protocol Version 0.8
- This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area of Internet payments. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1899 - Request for Comments Summary RFC Numbers 1800-1899
- RFC1900 - Renumbering Needs Work
- Hosts in an IP network are identified by IP addresses, and the IP address prefixes of subnets are advertised by routing protocols. A change in such IP addressing information associated with a host or subnet is known as "renumbering". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1909 - An Administrative Infrastructure for SNMPv2
- 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.
- RFC1910 - User-based Security Model for SNMPv2
- 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.
- RFC1911 - Voice Profile for Internet Mail
- The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community.
- RFC1912 - Common DNS Operational and Configuration Errors
- This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1915 - Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol
- 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.
- RFC1919 - Classical versus Transparent IP Proxies
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1920 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]
- RFC1921 - TNVIP Protocol
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1922 - Chinese Character Encoding for Internet Messages
- This memo describes methods of transporting Chinese characters in Internet services which transport text, such as electronic mail [RFC-822], network news [RFC-1036], telnet [RFC-854] and the World Wide Web [RFC-1866]. This memo provides information for the Internet community. It does not specify an Internet standard.
- RFC1924 - A Compact Representation of IPv6 Addresses
- 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.
- RFC1925 - The Twelve Networking Truths
- This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1926 - An Experimental Encapsulation of IP Datagrams on Top of ATM
- This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM). This is a non-recommended standard. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1927 - Suggested Additional MIME Types for Associating Documents
- 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.
- RFC1931 - Dynamic RARP Extensions for Automatic Network Address Acquisition
- 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.
- RFC1934 - Ascend's Multilink Protocol Plus (MP+)
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1935 - What is the Internet, Anyway?
- This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1936 - Implementing the Internet Checksum in Hardware
- This memo presents a techniques for efficiently implementing the Internet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1939 - Post Office Protocol - Version 3
- The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK]
- RFC1946 - Native ATM Support for ST2+
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1947 - Greek Character Encoding for Electronic Mail Messages
- 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.
- RFC1948 - Defending Against Sequence Number Attacks
- IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1950 - ZLIB Compressed Data Format Specification version 3.3
- This specification defines a lossless compressed data format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1951 - DEFLATE Compressed Data Format Specification version 1.3
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1952 - GZIP file format specification version 4.3
- This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1953 - Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0
- 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. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1954 - Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0
- 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]. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1955 - New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG
- This paper proposes a new scheme which I believe is a good medium term solution to the routing and address problems of the internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1956 - Registration in the MIL Domain
- 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.
- RFC1957 - Some Observations on Implementations of the Post Office Protocol (POP3)
- This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1958 - Architectural Principles of the Internet
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1980 - A Proposed Extension to HTML : Client-Side Image Maps
- The markup language known as "HTML/2.0" provides for image maps. Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified by Uniform 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.
- RFC1984 - IAB and IESG Statement on Cryptographic Technology and the Internet
- 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.
- RFC1985 - SMTP Service Extension for Remote Message Queue Starting
- 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. [STANDARDS-TRACK]
- RFC1986 - Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)
- 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.
- RFC1987 - Ipsilon's General Switch Management Protocol Specification Version 1.1
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC1988 - Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework
- 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.
- RFC1991 - PGP Message Exchange Formats
- 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.
- RFC1999 - Request for Comments Summary RFC Numbers 1900-1999
- RFC2000 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard.
- RFC2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
- Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [STANDARDS-TRACK]
- RFC2009 - GPS-Based Addressing and Routing
- 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.
- RFC2010 - Operational Criteria for Root Name Servers
- This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2014 - IRTF Research Group Guidelines and Procedures
- This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC2015 - MIME Security with Pretty Good Privacy (PGP)
- This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847. [STANDARDS-TRACK]
- RFC2016 - Uniform Resource Agents (URAs)
- This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. This memo defines an Experimental Protocol for the Internet community.
- RFC2030 - Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
- This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2033 - Local Mail Transfer Protocol
- 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.
- RFC2034 - SMTP Service Extension for Returning Enhanced Error Codes
- 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]
- RFC2039 - Applicability of Standards Track MIBs to Management of World Wide Web Servers
- 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.
- RFC2040 - The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms
- 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.
- RFC2041 - Mobile Network Tracing
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2042 - Registering New BGP Attribute Types
- 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.
- RFC2044 - UTF-8, a transformation format of Unicode and ISO 10646
- The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2050 - Internet Registry IP Allocation Guidelines
- 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 specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC2052 - A DNS RR for specifying the location of services (DNS SRV)
- 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). This memo defines an Experimental Protocol for the Internet community.
- RFC2053 - The AM (Armenia) Domain
- 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.
- RFC2054 - WebNFS Client Specification
- This document describes a lightweight binding mechanism that allows NFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2055 - WebNFS Server Specification
- This document describes the specifications for a server of WebNFS clients. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2056 - Uniform Resource Locators for Z39.50
- 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]
- RFC2057 - Source Directed Access Control on the Internet
- 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.
- RFC2060 - Internet Message Access Protocol - Version 4rev1
- The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. [STANDARDS-TRACK]
- RFC2061 - IMAP4 Compatibility with IMAP2bis
- 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.
- RFC2062 - Internet Message Access Protocol - Obsolete Syntax
- This document describes obsolete syntax which may be encountered by IMAP4 implementations which deal with older versions of the Internet Mail Access Protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2066 - TELNET CHARSET Option
- This document specifies a mechanism for passing character set and translation information between a TELNET client and server. This memo defines an Experimental Protocol for the Internet community.
- RFC2067 - IP over HIPPI
- ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is intended to replace it in the Standards Track. [STANDARDS-TRACK]
- RFC2075 - IP Echo Host Service
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC2077 - The Model Primary Content Type for Multipurpose Internet Mail Extensions
- 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]
- RFC2083 - PNG (Portable Network Graphics) Specification Version 1.0
- This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2086 - IMAP4 ACL extension
- The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]
- RFC2087 - IMAP4 QUOTA extension
- The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK]
- RFC2088 - IMAP4 non-synchronizing literals
- The Internet Message Access Protocol [STANDARDS-TRACK]
- RFC2089 - V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent
- The goal of this memo is to document a common way of mapping an SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2090 - TFTP Multicast Option
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC2093 - Group Key Management Protocol (GKMP) Specification
- This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.
- RFC2094 - Group Key Management Protocol (GKMP) Architecture
- This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.
- RFC2095 - IMAP/POP AUTHorize Extension for Simple Challenge/Response
- This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]
- RFC2098 - Toshiba's Router Architecture Extensions for ATM : Overview
- This memo describes a new internetworking architecture which makes better use of the property of ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2099 - Request for Comments Summary RFC Numbers 2000-2099
- RFC2100 - The Naming of Hosts
- 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.
- RFC2101 - IPv4 Address Behaviour Today
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2105 - Cisco Systems' Tag Switching Architecture Overview
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2106 - Data Link Switching Remote Access Protocol
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2107 - Ascend Tunnel Management Protocol - ATMP
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2113 - IP Router Alert Option
- This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]
- RFC2114 - Data Link Switching Client Access Protocol
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2122 - VEMMI URL Specification
- 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]
- RFC2124 - Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0
- This document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2126 - ISO Transport Service on top of TCP (ITOT)
- This document is a revision to STD35, 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. [STANDARDS-TRACK]
- RFC2129 - Toshiba's Flow Attribute Notification Protocol (FANP) Specification
- This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2130 - The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996
- 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 the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2134 - Articles of Incorporation of Internet Society
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2135 - Internet Society By-Laws
- These are the by-laws of the Internet Society, as amended, as of June 1996. 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2139 - RADIUS Accounting
- This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2140 - TCP Control Block Interdependence
- This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2142 - Mailbox Names for Common Services, Roles and Functions
- This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]
- RFC2143 - Encapsulating IP with the Small Computer System Interface
- 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.
- RFC2144 - The CAST-128 Encryption Algorithm
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2146 - U.S. Government Internet Domain Names
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2151 - A Primer On Internet and TCP/IP Tools and Utilities
- 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 obtain Internet and TCP/IP documents, and some 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.
- RFC2152 - UTF-7 A Mail-Safe Transformation Format of Unicode
- 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". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2154 - OSPF with Digital Signatures
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC2166 - APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2167 - Referral Whois (RWhois) Protocol V1.5
- This memo describes Version 1.5 of the client/server interaction of RWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2170 - Application REQuested IP over ATM (AREQUIPA)
- 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 memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2171 - MAPOS - Multiple Access Protocol over SONET/SDH Version 1
- This memo documents a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2172 - MAPOS Version 1 Assigned Numbers
- This memo documents the parameters used in the Multiple Access Protocol over SONET/SDH Version 1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2173 - A MAPOS version 1 Extension - Node Switch Protocol
- This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2174 - A MAPOS version 1 Extension - Switch-Switch Protocol
- This memo documents a MAPOS (Multiple Access Protocol over SONET/SDH) version 1 extension, Switch Switch Protocol which provides dynamic routing for unicast, broadcast, and multicast. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2175 - MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing
- This memo documents MAPOS 16, a multiple access protocol for transmission of network-protocol datagrams, encapsulated in HDLC frames with 16 bit addressing, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2176 - IPv4 over MAPOS Version 1
- This memo documents a mechanism for supporting Version 4 of the Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2177 - IMAP4 IDLE command
- 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]
- RFC2179 - Network Security For Trade Shows
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2180 - IMAP4 Multi-Accessed Mailbox Practice
- 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.
- RFC2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
- This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content- Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). [STANDARDS-TRACK]
- RFC2184 - MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
- This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]
- RFC2186 - Internet Cache Protocol (ICP), version 2
- This document describes version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2187 - Application of Internet Cache Protocol (ICP), version 2
- This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2188 - AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2
- This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2191 - VENUS - Very Extensive Non-Unicast Service
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2192 - IMAP URL Scheme
- This document defines a URL scheme for referencing objects on an IMAP server. [STANDARDS-TRACK]
- RFC2193 - IMAP4 Mailbox Referrals
- Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]
- RFC2195 - IMAP/POP AUTHorize Extension for Simple Challenge/Response
- This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]
- RFC2197 - SMTP Service Extension for Command Pipelining
- This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]
- RFC2199 - Request for Comments Summary RFC Numbers 2100-2199
- RFC2200 - Internet Official Protocol Standards
- A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]
- RFC2202 - Test Cases for HMAC-MD5 and HMAC-SHA-1
- 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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2204 - ODETTE File Transfer Protocol
- This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2217 - Telnet Com Port Control Option
- 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.
- RFC2220 - The Application/MARC Content-type
- 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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2221 - IMAP4 Login Referrals
- 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]
- RFC2222 - Simple Authentication and Security Layer (SASL)
- This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]
- RFC2223 - Instructions to RFC Authors
- This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
- RFC2224 - NFS URL Scheme
- 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 in RFC 1738, "Uniform Resource Locators (URL)". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2229 - A Dictionary Server Protocol
- 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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2230 - Key Exchange Delegation Record for the DNS
- 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.
- RFC2231 - MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
- This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. 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]
- RFC2235 - Hobbes' Internet Timeline
- 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.
- RFC2237 - Japanese Character Encoding for Internet Messages
- 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.
- RFC2240 - A Legal Basis for Domain Name Allocation
- The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2260 - Scalable Support for Multi-homed Multi-provider Connectivity
- 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.
- RFC2267 - Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
- 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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2268 - A Description of the RC2(r) Encryption Algorithm
- 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.
- RFC2271 - An Architecture for Describing SNMP Management Frameworks
- This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]
- RFC2272 - Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
- This document describes the Message Processing and Dispatching for SNMP 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. [STANDARDS-TRACK]
- RFC2273 - SNMPv3 Applications
- 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, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]
- RFC2274 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
- This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements 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. [STANDARDS-TRACK]
- RFC2275 - View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
- This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure 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. [STANDARDS-TRACK]
- RFC2277 - IETF Policy on Character Sets and Languages
- 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.
- RFC2278 - IANA Charset Registration Procedures
- MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC2279 - UTF-8, a transformation format of ISO 10646
- 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. [STANDARDS-TRACK]
- RFC2281 - Cisco Hot Standby Router Protocol (HSRP)
- 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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2286 - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
- This document provides two sets of test cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2297 - Ipsilon's General Switch Management Protocol Specification Version 2.0
- This memo specifies enhancements to the General Switch Management Protocol (GSMP) [RFC1987]. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2299 - Request for Comments Summary
- RFC2300 - Internet Official Protocol Standards
- A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]
- RFC2307 - An Approach for Using LDAP as a Network Information Service
- This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. 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.
- RFC2309 - Recommendations on Queue Management and Congestion Avoidance in the Internet
- 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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2311 - S/MIME Version 2 Message Specification
- 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.
- RFC2312 - S/MIME Version 2 Certificate Handling
- 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.
- RFC2313 - PKCS #1: RSA Encryption Version 1.5
- This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2314 - PKCS #10: Certification Request Syntax Version 1.5
- This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2315 - PKCS #7: Cryptographic Message Syntax Version 1.5
- 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.
- RFC2316 - Report of the IAB Security Architecture Workshop
- 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.
- RFC2318 - The text/css Media Type
- This memo provides information about the text/css Media Type. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2319 - Ukrainian Character Set KOI8-U
- This document provides information about character encoding KOI8-U (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2321 - RITA -- The Reliable Internetwork Troubleshooting Agent
- A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2322 - Management of IP numbers by peg-dhcp
- 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.
- RFC2323 - IETF Identification and Security Guidelines
- 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.
- RFC2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
- This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2325 - Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2
- 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.
- RFC2339 - An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols
- This Request for Comments records an agreement between Sun Microsystems, Inc. and the Internet Society to permit the flow of Sun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2340 - Nortel's Virtual Network Switching (VNS) Overview
- This document provides an overview of Virtual Network Switching (VNS). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2341 - Cisco Layer Two Forwarding (Protocol) "L2F"
- 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. This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind.
- RFC2342 - IMAP4 Namespace
- 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]
- RFC2345 - Domain Names and Company Name Retrieval
- 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. 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.
- RFC2346 - Making Postscript and PDF International
- Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable Document Format (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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2347 - TFTP Option Extension
- The Trivial File Transfer Protocol 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. [STANDARDS-TRACK]
- RFC2348 - TFTP Blocksize Option
- The Trivial File Transfer Protocol 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 TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]
- RFC2349 - TFTP Timeout Interval and Transfer Size Options
- The Trivial File Transfer Protocol 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. [STANDARDS-TRACK]
- RFC2351 - Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP
- This memo specifies a protocol for the encapsulation of the airline specific protocol over IP. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2352 - A Convention For Using Legal Names as Domain Names
- 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.
- RFC2353 - APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document
- 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.
- RFC2357 - IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols
- This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2359 - IMAP4 UIDPLUS extension
- The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK]
- RFC2361 - WAVE and AVI Codec Registries
- The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2367 - PF_KEY Key Management API, Version 2
- A generic key management API that can be used not only for IP Security but also for other network security services is presented in this document. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2368 - The mailto URL scheme
- This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. [STANDARDS-TRACK]
- RFC2369 - The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
- The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. 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. [STANDARDS-TRACK]
- RFC2376 - XML Media Types
- This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2383 - ST2+ over ATM Protocol Specification - UNI 3.1 Version
- This document specifies an ATM-based protocol for communication between ST2+ agents. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2384 - POP URL Scheme
- This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]
- RFC2388 - Returning Values from Forms: multipart/form-data
- This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK]
- RFC2391 - Load Sharing using IP Network Address Translation (LSNAT)
- 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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
- RFC2396 - Uniform Resource Identifiers (URI): Generic Syntax
- 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. [STANDARDS-TRACK]
- RFC2397 - The "data" URL scheme
- 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]
- RFC2399 - Request for Comments Summary
- RFC2400 - Internet Official Protocol Standards
- This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK]
- RFC2413 - Dublin Core Metadata for Resource Discovery
- 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.
- RFC2417 - Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
- 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. [STANDARDS-TRACK]
- RFC2421 - Voice Profile for Internet Mail - version 2
- This document profiles Internet mail for voice messaging. [STANDARDS-TRACK]
- RFC2422 - Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration
- This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]
- RFC2423 - VPIM Voice Message MIME Sub-type Registration
- This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK]
- RFC2424 - Content Duration MIME Header Definition
- This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]
- RFC2430 - A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)
- 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.
- RFC2436 - Collaboration between ISOC/IETF and ITU-T
- This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community.
- RFC2437 - PKCS #1: RSA Cryptography Specifications Version 2.0
- This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community.
- RFC2441 - Working with Jon, Tribute delivered at UCLA, October 30, 1998
- This memo provides information for the Internet community.
- RFC2442 - The Batch SMTP Media Type
- This document defines a MIME content type suitable for tunneling an ESMTP transaction through any MIME-capable transport. This memo provides information for the Internet community
- RFC2448 - AT&T's Error Resilient Video Transmission Technique
- 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. This memo provides information for the Internet community.
- RFC2449 - POP3 Extension Mechanism
- This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]
- RFC2468 - I REMEMBER IANA
- A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community.
- RFC2469 - A Caution On The Canonical Ordering Of Link-Layer Addresses
- 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. This memo provides information for the Internet community.
- RFC2476 - Message Submission
- 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]
- RFC2480 - Gateways and MIME Security Multiparts
- This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]
- RFC2481 - A Proposal to add Explicit Congestion Notification (ECN) to IP
- This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. This memo defines an Experimental Protocol for the Internet community.
- RFC2482 - Language Tagging in Unicode Plain Text
- This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community.
- RFC2487 - SMTP Service Extension for Secure SMTP over TLS
- This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]
- RFC2490 - A Simulation Model for IP Multicast with RSVP
- This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package, with protocol procedures defined in the C language. This memo provides information for the Internet community.
- RFC2498 - IPPM Metrics for Measuring Connectivity
- This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community.
- RFC2499 - Request for Comments Summary
- RFC2500 - Internet Official Protocol Standards
- This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK]
- RFC2503 - MIME Types for Use with the ISO ILL Protocol
- This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161). This memo provides information for the Internet community.
- RFC2505 - Anti-Spam Recommendations for SMTP MTAs
- This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail,) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC2516 - A Method for Transmitting PPP Over Ethernet (PPPoE)
- This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This memo provides information for the Internet community.
- RFC2517 - Building Directories from DNS: Experiences from WWWSeeker
- This memo discusses lessons that were learned during InterNIC Directory and Database Services' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. This memo provides information for the Internet community.
- RFC2521 - ICMP Security Failures Messages
- This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). This document defines an Experimental Protocol for the Internet community.
- RFC2522 - Photuris: Session-Key Management Protocol
- This document defines the basic protocol mechanisms. This document defines an Experimental Protocol for the Internet community.
- RFC2523 - Photuris: Extended Schemes and Attributes
- Photuris is a session-key management protocol. Extensible Exchange- Schemes are provided to enable future implementation changes without affecting the basic protocol. This document defines an Experimental Protocol for the Internet community.
- RFC2524 - Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3
- 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.
- RFC2544 - Benchmarking Methodology for Network Interconnect Devices
- This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community.
- RFC2547 - BGP/MPLS VPNs
- This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. This memo provides information for the Internet community.
- RFC2549 - IP over Avian Carriers with Quality of Service
- This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", with Quality of Service information. This is an experimental, not recommended standard. This memo defines an Experimental Protocol for the Internet community.
- RFC2550 - Y10K and Beyond
- This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). This memo provides information for the Internet community.
- RFC2551 - The Roman Standards Process -- Revision III
- 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.
- RFC2552 - Architecture for the Information Brokerage in the ACTS Project GAIA
- 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). This memo provides information for the Internet community.
- RFC2554 - SMTP Service Extension for Authentication
- This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK]
- RFC2555 - 30 Years of RFCs
- 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.
- RFC2556 - OSI connectionless transport services on top of UDP Applicability Statement for Historic Status
- 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 This memo provides information for the Internet community.
- RFC2578 - Structure of Management Information Version 2 (SMIv2)
- 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]
- RFC2579 - Textual Conventions for SMIv2
- It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]
- RFC2580 - Conformance Statements for SMIv2
- 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]
- RFC2586 - The Audio/L16 MIME content type
- 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.
- RFC2593 - Script MIB Extensibility Protocol Version 1.0
- The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. This memo defines an Experimental Protocol for the Internet community.
- RFC2595 - Using TLS with IMAP, POP3 and ACAP
- 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]
- RFC2599 - Request for Comments Summary RFC Numbers 2500-2599
- RFC2600 - Internet Official Protocol Standards
- This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK]
- RFC2604 - Wireless Device Configuration (OTASP/OTAPA) via ACAP
- This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.
- RFC2612 - The CAST-256 Encryption Algorithm
- 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). This memo provides information for the Internet community.
- RFC2627 - Key Management for Multicast: Issues and Architectures
- 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. This memo provides information for the Internet community.
- RFC2628 - Simple Cryptographic Program Interface (Crypto API)
- This document describes a simple Application Program Interface to cryptographic functions. This memo provides information for the Internet community.
- RFC2629 - Writing I-Ds and RFCs using XML
- This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.
- RFC2636 - Wireless Device Configuration (OTASP/OTAPA) via ACAP
- This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.
- RFC2638 - A Two-bit Differentiated Services Architecture for the Internet
- This document presents a differentiated services architecture for the internet. This memo provides information for the Internet community.
- RFC2641 - Cabletron's VlanHello Protocol Specification Version 4
- 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. This memo provides information for the Internet community.
- RFC2642 - Cabletron's VLS Protocol Specification
- 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. This memo provides information for the Internet community.
- RFC2643 - Cabletron's SecureFast VLAN Operational Model
- 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. This memo provides information for the Internet community.
- RFC2644 - Changing the Default for Directed Broadcasts in Routers
- 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.
- RFC2645 - ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses
- 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]
- RFC2646 - The Text/Plain Format Parameter
- This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]
- RFC2658 - RTP Payload Format for PureVoice(tm) Audio
- This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]
- RFC2678 - IPPM Metrics for Measuring Connectivity
- This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]
- RFC2682 - Performance Issues in VC-Merge Capable ATM LSRs
- This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. This memo provides information for the Internet community.
- RFC2683 - IMAP4 Implementation Recommendations
- 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.
- RFC2697 - A Single Rate Three Color Marker
- This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community.
- RFC2698 - A Two Rate Three Color Marker
- This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community.
- RFC2699 - Request for Comments Summary RFC Numbers 2600-2699
- RFC2700 - Internet Official Protocol Standards
- This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering Task Force (IETF). [STANDARDS-TRACK]
- RFC2704 - The KeyNote Trust-Management System Version 2
- 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. This memo provides information for the Internet community.
- RFC2705 - Media Gateway Control Protocol (MGCP) Version 1.0
- 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. This memo provides information for the Internet community.
- RFC2706 - ECML v1: Field Names for E-Commerce
- 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. This memo provides information for the Internet community.
- RFC2713 - Schema for Representing Java(tm) Objects in an LDAP Directory
- This document defines the schema for representing Java(tm) objects in an LDAP directory. This memo provides information for the Internet community.
- RFC2714 - Schema for Representing CORBA Object References in an LDAP Directory
- This document defines the schema for representing CORBA object references in an LDAP directory. This memo provides information for the Internet community.
- RFC2731 - Encoding Dublin Core Metadata in HTML
- The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community.
- RFC2755 - Security Negotiation for WebNFS
- 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. This memo provides information for the Internet community.
- RFC2756 - Hyper Text Caching Protocol (HTCP/0.0)
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC2757 - Long Thin Networks
- Our goal is to identify a TCP that works for all users, including users of long thin networks. This memo provides information for the Internet community.
- RFC2758 - Definitions of Managed Objects for Service Level Agreements Performance Monitoring
- This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. This memo defines an Experimental Protocol for the Internet community.
- RFC2764 - A Framework for IP Based Virtual Private Networks
- This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community.
- RFC2768 - Network Policy and Services: A Report of a Workshop on Middleware
- An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified. This memo provides information for the Internet community.
- RFC2774 - An HTTP Extension Framework
- A wide range of applications have proposed various extensions of the HTTP 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.
- RFC2775 - Internet Transparency
- This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency.
- RFC2780 - IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers
- This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC2781 - UTF-16, an encoding of ISO 10646
- 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.
- RFC2783 - Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0
- 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. This memo provides information for the Internet community.
- RFC2784 - Generic Routing Encapsulation (GRE)
- This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-TRACK]
- RFC2786 - Diffie-Helman USM Key Management Information Base and Textual Convention
- This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges an set of objects which extend the usmUserTable to permit the use of DH key exchange in addition to the key change method. This memo defines an Experimental Protocol for the Internet community.
- RFC2790 - Host Resources MIB
- 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 Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. [STANDARDS-TRACK]
- RFC2792 - DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System
- This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. This memo provides information for the Internet community.
- RFC2795 - The Infinite Monkey Protocol Suite (IMPS)
- 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 of William Shakespeare or a good television show. This memo provides information for the Internet community.
- RFC2798 - Definition of the inetOrgPerson LDAP Object Class
- 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. This memo provides information for the Internet community.
- RFC2799 - Request for Comments Summary RFC Numbers 2700-2799
- RFC2800 - Internet Official Protocol Standards
- This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to the RFC series. [STANDARDS-TRACK]
- RFC2804 - IETF Policy on Wiretapping
- This document describes the position that the Internet Engineering Task Force (IETF) has taken regarding 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. This memo provides information for the Internet community.
- RFC2806 - URLs for Telephone Calls
- This document specifies URL (Uniform Resource Locator) schemes "tel", "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. [STANDARDS-TRACK]
- RFC2808 - The SecurID(r) SASL Mechanism
- This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism using SecurID (a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication), thereby providing a means for such tokens to be used in SASL environments. This mechanism is only is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services. This memo provides information for the Internet community.
- RFC2825 - A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols
- 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. This memo provides information for the Internet community.
- RFC2826 - IAB Technical Comment on the Unique DNS Root
- 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.
- RFC2828 - Internet Security Glossary
- This Glossary provides abbreviations, explanations, and recommendations for use of information system security terminology. This memo provides information for the Internet community.
- RFC2831 - Using Digest Authentication as a SASL Mechanism
- This specification defines how HTTP Digest Authentication can be used as a SASL mechanism for any protocol that has a SASL (Simple Authentication and Security Layer) profile. [STANDARDS-TRACK]
- RFC2832 - NSI Registry Registrar Protocol (RRP) Version 1.1.0
- 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 Level Domains (ccTLDs). This memo provides information for the Internet community.
- RFC2835 - IP and ARP over HIPPI-6400 (GSN)
- This document further specifies a method for resolving IP addresses to HIPPI-6400 (High-Performance Parallel Interface) 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. [STANDARDS-TRACK]
- RFC2838 - Uniform Resource Identifiers for Television Broadcasts
- 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.
- RFC2839 - Internet Kermit Service
- 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.
- RFC2840 - TELNET KERMIT OPTION
- 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.
- RFC2841 - IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)
- This document describes the use of keyed SHA1 (Secure Hash Algorithm) with the IP Authentication Header. This memo defines a Historic Document for the Internet community.
- RFC2850 - Charter of the Internet Architecture Board (IAB)
- This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC2851 - Textual Conventions for Internet Network Addresses
- This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. [STANDARDS-TRACK]
- RFC2852 - Deliver By SMTP Service Extension
- 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. [STANDARDS-TRACK]
- RFC2854 - The 'text/html' Media Type
- This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations. This memo provides information for the Internet community.
- RFC2856 - Textual Conventions for Additional High Capacity Data Types
- This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. [STANDARDS-TRACK]
- RFC2859 - A Time Sliding Window Three Colour Marker (TSWTCM)
- This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner. This memo defines an Experimental Protocol for the Internet community.
- RFC2860 - Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority
- This document places on record the text of the Memorandum of Understanding 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. This memo provides information for the Internet community.
- RFC2873 - TCP Processing of the IPv4 Precedence Field
- This memo describes a conflict between TCP and DiffServ on the use of the three leftmost bits in the TOS octet of an IPv4 header. [STANDARDS-TRACK]
- RFC2884 - Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks
- This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. This memo provides information for the Internet community.
- RFC2888 - Secure Remote Access with L2TP
- The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This memo provides information for the Internet community.
- RFC2890 - Key and Sequence Number Extensions to GRE
- This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK]
- RFC2892 - The Cisco SRP MAC Layer Protocol
- This document specifies the MAC layer protocol, "Spatial Reuse Protocol" (SRP) for use with ring based media. This is a second version of the protocol (V2). This memo provides information for the Internet community.
- RFC2897 - Proposal for an MGCP Advanced Audio Package
- This document is a proposal to add a new event/signal package to the MGCP (Media Gateway Control Protocol) protocol to control an ARF (Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server. This memo provides information for the Internet community.
- RFC2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0
- 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 memo provides information for the Internet community.
- RFC2899 - Request for Comments Summary RFC Numbers 2800-2899
- RFC2900 - Internet Official Protocol Standards
- This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. This memo is an Internet Standard.
- RFC2901 - Guide to Administrative Procedures of the Internet Infrastructure
- This document describes the administrative procedures for networks seeking to connect to the global Internet. This memo provides information for the Internet community.
- RFC2902 - Overview of the 1998 IAB Routing Workshop
- This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998. This memo provides information for the Internet community.
- RFC2903 - Generic AAA Architecture
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC2904 - AAA Authorization Framework
- This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. This memo provides information for the Internet community.
- RFC2905 - AAA Authorization Application Examples
- This memo describes several examples of applications requiring authorization. This memo provides information for the Internet community.
- RFC2906 - AAA Authorization Requirements
- This document specifies the requirements that Authentication Authorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. This memo provides information for the Internet community.
- RFC2917 - A Core MPLS IP VPN Architecture
- This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This memo provides information for the Internet community.
- RFC2920 - SMTP Service Extension for Command Pipelining
- 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 Control Protocol (TCP) send operation. [STANDARDS-TRACK]
- RFC2941 - Telnet Authentication Option
- This document describes the authentication option to the telnet protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. [STANDARDS-TRACK]
- RFC2942 - Telnet Authentication: Kerberos Version 5
- This document describes how Kerberos Version 5 is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option. [STANDARDS-TRACK]
- RFC2943 - TELNET Authentication Using DSA
- This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA). It relies on the Telnet Authentication Option. [STANDARDS-TRACK]
- RFC2944 - Telnet Authentication: SRP
- This document specifies an authentication scheme for the Telnet protocol under the framework described in RFC 2941, using the Secure Remote Password Protocol (SRP) authentication mechanism. [STANDARDS-TRACK]
- RFC2945 - The SRP Authentication and Key Exchange System
- This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS-TRACK]
- RFC2946 - Telnet Data Encryption Option
- This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. [STANDARDS-TRACK]
- RFC2947 - Telnet Encryption: DES3 64 bit Cipher Feedback
- This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option. [STANDARDS-TRACK]
- RFC2948 - Telnet Encryption: DES3 64 bit Output Feedback
- This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option. [STANDARDS-TRACK]
- RFC2949 - Telnet Encryption: CAST-128 64 bit Output Feedback
- 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. [STANDARDS-TRACK]
- RFC2950 - Telnet Encryption: CAST-128 64 bit Cipher Feedback
- 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. [STANDARDS-TRACK]
- RFC2951 - TELNET Authentication Using KEA and SKIPJACK
- This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. This memo provides information for the Internet community.
- RFC2952 - Telnet Encryption: DES 64 bit Cipher Feedback
- This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option. This memo provides information for the Internet community.
- RFC2953 - Telnet Encryption: DES 64 bit Output Feedback
- This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option. This memo provides information for the Internet community.
- RFC2956 - Overview of 1999 IAB Network Layer Workshop
- This document is an overview of a workshop held by the Internet Architecture 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. This memo provides information for the Internet community.
- RFC2957 - The application/whoispp-query Content-Type
- 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. This memo provides information for the Internet community.
- RFC2958 - The application/whoispp-response Content-type
- 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. This memo provides information for the Internet community.
- RFC2963 - A Rate Adaptive Shaper for Differentiated Services
- 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 and RFC2698, respectively. This memo provides information for the Internet community.
- RFC2967 - TISDAG - Technical Infrastructure for Swedish Directory Access Gateways
- The overarching goal of this project is to develop the necessary technical infrastructure to provide a single-access-point service for searching for whitepages information on Swedish Internet users. This memo provides information for the Internet community.
- RFC2968 - Mesh of Multiple DAG servers - Results from TISDAG
- This document defines the basic principle for establishing a mesh, that interoperating services should exchange index objects, according to the architecture of the mesh (e.g., hierarchical, or graph-like, preferably without loops!). The Common Indexing Protocol (CIP) 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 has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services. This memo provides information for the Internet community.
- RFC2969 - Wide Area Directory Deployment - Experiences from TISDAG
- 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. This memo provides information for the Internet community.
- RFC2971 - IMAP4 ID extension
- This document describes an ID extension which will enable Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) to advertise what program a client or server uses to provide service. The ID extension allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. [STANDARDS-TRACK]
- RFC2972 - Context and Goals for Common Name Resolution
- This document establishes the context and goals for a Common Name Resolution Protocol. This memo provides information for the Internet community.
- RFC2978 - IANA Charset Registration Procedures
- Multipurpose Internet Mail Extensions (MIME) 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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC2979 - Behavior of and Requirements for Internet Firewalls
- This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. This memo provides information for the Internet community.
- RFC2985 - PKCS #9: Selected Object Classes and Attribute Types Version 2.0
- This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' 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 information for the Internet community.
- RFC2986 - PKCS #10: Certification Request Syntax Specification Version 1.7
- This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' 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 provides information for the Internet community.
- RFC2987 - Registration of Charset and Languages Media Features Tags
- This document contains the registration for two media feature tags: "charset" and "language". [STANDARDS-TRACK]
- RFC2990 - Next Steps for the IP QoS Architecture
- 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. This memo provides information for the Internet community.
- RFC2991 - Multipath Issues in Unicast and Multicast Next-Hop Selection
- 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. This memo summarizes current practices, problems, and solutions. This memo provides information for the Internet community.
- RFC2992 - Analysis of an Equal-Cost Multi-Path Algorithm
- 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. This memo provides information for the Internet community.
- RFC2993 - Architectural Implications of NAT
- This document discusses some of the architectural implications and guidelines for implementations of Network Address Translation (NAT). This memo provides information for the Internet community.
- RFC2994 - A Description of the MISTY1 Encryption Algorithm
- 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. This memo provides information for the Internet community.
- RFC2999 - Request for Comments Summary RFC Numbers 2900-2999
- RFC3000 - Internet Official Protocol Standards
- This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]
- RFC3001 - A URN Namespace of Object Identifiers
- This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.
- RFC3002 - Overview of 2000 IAB Wireless Internetworking Workshop
- This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. This memo provides information for the Internet community.
- RFC3003 - The audio/mpeg Media Type
- The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose Internet Mail 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. [STANDARDS-TRACK]
- RFC3018 - Unified Memory Space Protocol Specification
- This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes. This memo defines an Experimental Protocol for the Internet community.
- RFC3021 - Using 31-Bit Prefixes on IPv4 Point-to-Point Links
- With ever-increasing pressure to conserve IP address space on the Internet, 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 the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. [STANDARDS-TRACK]
- RFC3023 - XML Media Types
- This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (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 Mail Extensions) entities. [STANDARDS-TRACK]
- RFC3028 - Sieve: A Mail Filtering Language
- This document describes a language for filtering e-mail messages at time of final delivery. [STANDARDS-TRACK]
- RFC3030 - SMTP Service Extensions for Transmission of Large and Binary MIME Messages
- This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS-TRACK]
- RFC3043 - The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations
- This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations. This memo provides information for the Internet community.
- RFC3044 - Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace
- This document presents how the ISSN - International Standard Serial Number - 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. This memo provides information for the Internet community.
- RFC3045 - Storing Vendor Information in the LDAP root DSE
- 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. This memo provides information for the Internet community.
- RFC3050 - Common Gateway Interface for SIP
- This document defines a SIP CGI interface for providing SIP services on a SIP server. This memo provides information for the Internet community.
- RFC3051 - IP Payload Compression Using ITU-T V.44 Packet Method
- This document describes a compression method based on the data compression algorithm described in International Telecommunication Union (ITU-T) Recommendation V.44. This document defines the application of V.44 Packet Method to the Internet Protocol (IP) Payload Compression Protocol (RFC 2393). This memo provides information for the Internet community.
- RFC3052 - Service Management Architectures Issues and Review
- 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. This memo provides information for the Internet community.
- RFC3059 - Attribute List Extension for the Service Location Protocol
- 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. [STANDARDS-TRACK]
- RFC3061 - A URN Namespace of Object Identifiers
- This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.
- RFC3062 - LDAP Password Modify Extended Operation
- 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. [STANDARDS-TRACK]
- RFC3064 - MGCP CAS Packages
- This document contains a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. This memo provides information for the Internet community.
- RFC3066 - Tags for the Identification of Languages
- This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC3067 - TERENA'S Incident Object Description and Exchange Format Requirements
- 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 (Computer Security 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. This memo provides information for the Internet community.
- RFC3069 - VLAN Aggregation for Efficient IP Address Allocation
- This document introduces the concept of Virtual Local Area Network (VLAN) aggregation as it relates to IPv4 address allocation. This memo provides information for the Internet community.
- RFC3071 - Reflections on the DNS, RFC 1591, and Categories of Domains
- This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how 1591 might have been interpreted and adjusted by the Internet Assigned 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. This memo provides information for the Internet community.
- RFC3072 - Structured Data Exchange Format (SDXF)
- This specification describes an all-purpose interchange format for use as a file format or for net-working. This memo provides information for the Internet community.
- RFC3073 - Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration
- This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification. This memo provides information for the Internet community.
- RFC3079 - Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)
- 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. This memo provides information for the Internet community.
- RFC3082 - Notification and Subscription for SLP
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC3085 - URN Namespace for NewsML Resources
- This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. This memo provides information for the Internet community.
- RFC3087 - Control of Service Context using SIP Request-URI
- This memo describes a useful way to conceptualize the use of the standard SIP (Session Initiation Protocol) Request-URI (Uniform Resource Identifier) 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. This memo provides information for the Internet community.
- RFC3088 - OpenLDAP Root Service An experimental LDAP referral service
- The OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol) referral service known as the "OpenLDAP Root Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain Name System location of services resource records). This document describes this service. This memo defines an Experimental Protocol for the Internet community.
- RFC3091 - Pi Digit Generation Protocol
- This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. This memo provides information for the Internet community.
- RFC3092 - Etymology of "Foo"
- 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. This memo provides information for the Internet community.
- RFC3093 - Firewall Enhancement Protocol (FEP)
- 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 the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. This memo provides information for the Internet community.
- RFC3094 - Tekelec's Transport Adapter Layer Interface
- This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. This memo provides information for the Internet community.
- RFC3099 - Request for Comments Summary RFC Numbers 3000-3099
- RFC3106 - ECML v1.1: Field Specifications for E-Commerce
- 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. This memo provides information for the Internet community.
- RFC3109 - Request to Move STD 39 to Historic Status
- This memo changes the status of STD 39, BBN Report 1822, "Specification of the Interconnection of a Host and an IMP", from Standard to Historic. This memo provides information for the Internet community.
- RFC3112 - LDAP Authentication Password Schema
- This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This memo provides information for the Internet community.
- RFC3113 - 3GPP-IETF Standardization Collaboration
- This document describes the standardization collaboration between 3GPP and IETF. This memo provides information for the Internet community.
- RFC3117 - On the Design of Application Protocols
- This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). This memo provides information for the Internet community.
- RFC3120 - A URN Namespace for XML.org
- This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information 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). This memo provides information for the Internet community.
- RFC3121 - A URN Namespace for OASIS
- This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.
- RFC3128 - Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)
- 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. This memo provides information for the Internet community.
- RFC3130 - Notes from the State-Of-The-Technology: DNSSEC
- This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting. This memo provides information for the Internet community.
- RFC3131 - 3GPP2-IETF Standardization Collaboration
- This document describes the standardization collaboration between 3GPP2 and IETF. This memo provides information for the Internet community.
- RFC3139 - Requirements for Configuration Management of IP-based Networks
- This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP-based networks. This memo provides information for the Internet community.
- RFC3141 - CDMA2000 Wireless Data Requirements for AAA
- 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. This memo provides information for the Internet community.
- RFC3143 - Known HTTP Proxy/Caching Problems
- 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. This memo provides information for the Internet community.
- RFC3147 - Generic Routing Encapsulation over CLNS Networks
- This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network using GRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS. This memo provides information for the Internet community.
- RFC3149 - MGCP Business Phone Packages
- This document describes a collection of MGCP (Media Gateway Control Protocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones. This memo provides information for the Internet community.
- RFC3151 - A URN Namespace for Public Identifiers
- 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. This memo provides information for the Internet community.
- RFC3152 - Delegation of IP6.ARPA
- This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC3162 - RADIUS and IPv6
- This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. [STANDARDS-TRACK]
- RFC3163 - ISO/IEC 9798-3 Authentication SASL Mechanism
- This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication. This memo defines an Experimental Protocol for the Internet community.
- RFC3166 - Request to Move RFC 1403 to Historic Status
- RFC 1403, "BGP OSPF Interaction", describes technology which is no longer used. This document requests that RFC 1403 be moved to Historic status. This memo provides information for the Internet community.
- RFC3167 - Request to Move RFC 1745 to Historic Status
- 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. This memo provides information for the Internet community.
- RFC3172 - Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")
- This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC3173 - IP Payload Compression Protocol (IPComp)
- This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]
- RFC3174 - US Secure Hash Algorithm 1 (SHA1)
- The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community.
- RFC3176 - InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks
- This memo defines InMon Corporation'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. This memo provides information for the Internet community.
- RFC3179 - Script MIB Extensibility Protocol Version 1.1
- The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. This memo defines an Experimental Protocol for the Internet community.
- RFC3186 - MAPOS/PPP Tunneling mode
- This document specifies tunneling configuration over MAPOS (Multiple Access Protocol over SONET/SDH) networks. Using this mode, a MAPOS network can provide transparent point-to-point link for PPP over SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead. This memo provides information for the Internet community.
- RFC3187 - Using International Standard Book Numbers as Uniform Resource Names
- This document discusses how International Standard Book Numbers (ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.
- RFC3188 - Using National Bibliography Numbers as Uniform Resource Names
- This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.
- RFC3194 - The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio
- This document provides an update on the "H ratio" defined in RFC 1715. It defines a new ratio which the authors claim is easier to understand. This memo provides information for the Internet community.
- RFC3199 - Request for Comments Summary RFC Numbers 3100-3199
- RFC3205 - On the use of HTTP as a Substrate
- Recently there has been widespread interest in using Hypertext Transfer 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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC3206 - The SYS and AUTH POP Response Codes
- 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. [STANDARDS-TRACK]
- RFC3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security
- This document describes an extension to the SMTP (Simple Mail Transfer 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. [STANDARDS-TRACK]
- RFC3208 - PGM Reliable Transport Protocol Specification
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC3221 - Commentary on Inter-Domain Routing in the Internet
- 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 memo provides information for the Internet community.
- RFC3224 - Vendor Extensions for Service Location Protocol, Version 2
- This document specifies how the features of the Service Location Protocol, 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 Service Location Protocol." [STANDARDS-TRACK]
- RFC3229 - Delta encoding in HTTP
- This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS-TRACK]
- RFC3230 - Instance Digests in HTTP
- 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. [STANDARDS-TRACK]
- RFC3232 - Assigned Numbers: RFC 1700 is Replaced by an On-line Database
- This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community.
- RFC3233 - Defining the IETF
- This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC3234 - Middleboxes: Taxonomy and Issues
- 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. This memo provides information for the Internet community.
- RFC3236 - The 'application/xhtml+xml' Media Type
- This document defines the 'application/xhtml+xml' MIME media type for XHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers 'text/html'. This memo provides information for the Internet community.
- RFC3238 - IAB Architectural and Policy Considerations for Open Pluggable Edge Services
- This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open 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. This memo provides information for the Internet community.
- RFC3240 - Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration
- 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". This memo provides information for the Internet community.
- RFC3244 - Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols
- 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. This memo provides information for the Internet community.
- RFC3245 - The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)
- 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 Study Group 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.
- RFC3251 - Electricity over IP
- 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 memo provides information for the Internet community.
- RFC3252 - Binary Lexical Octet Ad-hoc Transport
- This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community.
- RFC3254 - Definitions for talking about directories
- When discussing systems for making information accessible through the Internet 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". This memo provides information for the Internet community.
- RFC3299 - Request for Comments Summary RFC Numbers 3200-3299
- RFC3300 - Internet Official Protocol Standards
- RFC3305 - Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations
- RFC3330 - Special-Use IPv4 Addresses
- RFC3334 - Policy-Based Accounting
- RFC3352 - Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status
- RFC3356 - Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines
- RFC3360 - Inappropriate TCP Resets Considered Harmful
- RFC3362 - Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration
- RFC3365 - Strong Security Requirements for Internet Engineering Task Force Standard Protocols
- RFC3367 - Common Name Resolution Protocol (CNRP)
- RFC3368 - The 'go' URI Scheme for the Common Name Resolution Protocol
- RFC3378 - EtherIP: Tunneling Ethernet Frames in IP Datagrams
- RFC3385 - Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations
- RFC3387 - Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network
- RFC3391 - The MIME Application/Vnd.pwg-multiplexed Content-Type
- RFC3419 - Textual Conventions for Transport Addresses
- 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. [STANDARDS-TRACK]
- RFC3423 - XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0
- This document defines the Common Reliable Accounting for Network Element (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. This memo provides information for the Internet community.
- RFC3424 - IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
- 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-Address Fixing (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. This memo provides information for the Internet community.
- RFC3426 - General Architectural and Policy Considerations
- 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. This memo provides information for the Internet community.
- RFC3427 - Change Process for the Session Initiation Protocol (SIP)
- This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC3488 - Cisco Systems Router-port Group Management Protocol (RGMP)
- 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. This memo provides information for the Internet community.
- RFC3494 - Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status
- This document recommends the retirement of version 2 of the Lightweight 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. This memo provides information for the Internet community.
- RFC3496 - Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering
- This document specifies a Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) signaling extension for support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. This memo provides information for the Internet community.
- RFC3499 - Request for Comments Summary RFC Numbers 3400-3499
- RFC3502 - Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
- This document describes the multiappending extension to the Internet Message 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". [STANDARDS-TRACK]
- RFC3503 - Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)
- The Message Disposition Notification (MDN) facility defined in RFC 2298 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. [STANDARDS-TRACK]
- RFC3507 - Internet Content Adaptation Protocol (ICAP)
- 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 pass HTTP 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. This memo provides information for the Internet community.
- RFC3508 - H.323 Uniform Resource Locator (URL) Scheme Registration
- ITU-T Recommendation H.323 version 4 introduced an H.323-specific Uniform 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). This memo provides information for the Internet community.
- RFC3514 - The Security Flag in the IPv4 Header
- 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. This memo provides information for the Internet community.
- RFC3528 - Mesh-enhanced Service Location Protocol (mSLP)
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC3529 - Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)
- 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 Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. This memo defines an Experimental Protocol for the Internet community.
- RFC3533 - The Ogg Encapsulation Format Version 0
- 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. This memo provides information for the Internet community. This memo provides information for the Internet community.
- RFC3535 - Overview of the 2002 IAB Network Management Workshop
- This document provides an overview of a workshop held by the Internet Architecture 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 the IETFs 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. This memo provides information for the Internet community.
- RFC3536 - Terminology Used in Internationalization in the IETF
- This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo provides information for the Internet community.
- RFC3541 - A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D)
- 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 Modeling Language (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. This memo provides information for the Internet community.
- RFC3548 - The Base16, Base32, and Base64 Data Encodings
- This document describes the commonly used base 64, base 32, and base 16 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. This memo provides information for the Internet community.
- RFC3552 - Guidelines for Writing RFC Text on Security Considerations
- 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 Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC3553 - An IETF URN Sub-namespace for Registered Protocol Parameters
- 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 to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC3572 - Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)
- Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- layer protocol that provides multiple access capability over a Synchronous 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 forming IPv6 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. This memo provides information for the Internet community.
- RFC3576 - Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
- This document describes a currently deployed extension to the Remote Authentication 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. This memo provides information for the Internet community.
- RFC3580 - IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines
- This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.
- RFC3589 - Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5
- This document describes the IANA's allocation of a block of Diameter Command 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. This memo provides information for the Internet community.
- RFC3599 - Request for Comments Summary RFC Numbers 3500-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.
- RFC3600 - Internet Official Protocol Standards
- This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.
- RFC3603 - Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
- 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 Distributed Call 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.
- RFC3607 - Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool
- 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.
- RFC3610 - Counter with CBC-MAC (CCM)
- 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).
- RFC3613 - Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE)
- 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.
- RFC3614 - A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG)
- 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.
- RFC3615 - A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging
- This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.
- RFC3616 - A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA)
- This document describes a Uniform Resource Name Namespace Identification (URN NID) for the Foundation for Intelligent Physical Agents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology.
- RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)
- 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.
- RFC3619 - Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1
- 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 by SONET rings, at a lower cost and with fewer constraints (e.g., ring size).
- RFC3622 - A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project
- This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.
- RFC3624 - The Media Gateway Control Protocol (MGCP) Bulk Audit Package
- 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.
- RFC3625 - The QCP File Format and Media Types for Speech Data
- RFC 2658 specifies the streaming format for 3GPP2 13KK vocoder (High Rate Speech Service Option 17 for Wideband Spread Spectrum Communications 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 for EVRC and SMV (respectively) data stored in this format.
- RFC3627 - Use of /127 Prefix Length Between Routers Considered Harmful
- In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.
- RFC3631 - Security Mechanisms for the Internet
- 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.
- RFC3632 - VeriSign Registry Registrar Protocol (RRP) Version 2.0.0
- 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 the VeriSign Registry Registrar Protocol.
- RFC3639 - Considerations on the use of a Service Identifier in Packet Headers
- 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.
- RFC3650 - Handle System Overview
- 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. The Handle System is a general-purpose global name service that allows secured name resolution and administration over networks such as the Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources.
- RFC3651 - Handle System Namespace and Service Definition
- The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document provides a detailed description of the Handle 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 the Handle 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.
- RFC3652 - Handle System Protocol (ver 2.1) Specification
- The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. 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.
- RFC3656 - The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol
- 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 Internet Message 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.
- RFC3660 - Basic Media Gateway Control Protocol (MGCP) Packages
- This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (Dual Tone 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.
- RFC3661 - Media Gateway Control Protocol (MGCP) Return Code Usage
- 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 the Call 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.
- RFC3662 - A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services
- 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.
- RFC3663 - Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)
- 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.
- RFC3675 - .sex Considered Dangerous
- 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.
- RFC3677 - IETF ISOC Board of Trustee Appointment Procedures
- This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.
- RFC3682 - The Generalized TTL Security Mechanism (GTSM)
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC3696 - Application Techniques for Checking and Transformation of Names
- 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. This memo provides information for the Internet community.
- RFC3700 - Internet Official Protocol Standards
- This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]
- RFC3701 - 6bone (IPv6 Testing Address Allocation) Phaseout
- 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. This memo provides information for the Internet community.
- RFC3712 - Lightweight Directory Access Protocol (LDAP): Schema for Printer Services
- This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). This memo provides information for the Internet community.
- RFC3714 - IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet
- 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 over Internet 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 the Internet, 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. This memo provides information for the Internet community.
- RFC3716 - IETF in the Large: Administration and Execution
- In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, 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 provides information for the Internet community.
- RFC3718 - A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access
- This memo describes various internal workings of the Unicode Consortium 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.
- RFC3724 - The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture
- The end-to-end principle is the core architectural guideline of the Internet. 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. This memo provides information for the Internet community.
- RFC3743 - Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean
- 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. This memo provides information for the Internet community.
- RFC3751 - Omniscience Protocol Requirements
- 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, the Omniscience Protocol, that could be used to enable such efforts. This memo provides information for the Internet community.
- RFC3754 - IP Multicast in Differentiated Services (DS) Networks
- This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results. This memo provides information for the Internet community.
- RFC3765 - NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control
- This document describes the use of a scope control Border Gateway Protocol (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. This memo provides information for the Internet community.
- RFC3780 - SMIng - Next Generation Structure of Management Information
- This memo defines the base SMIng (Structure of Management Information, 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. This memo defines an Experimental Protocol for the Internet community.
- RFC3781 - Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC3806 - Printer Finishing MIB
- 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 Printer System. This memo provides information for the Internet community.
- RFC3808 - IANA Charset MIB
- 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 by IANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset Registration Procedures (RFC 2978). This memo provides information for the Internet community.
- RFC3869 - IAB Concerns and Recommendations Regarding Internet Research and Evolution
- 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. This memo provides information for the Internet community.
- RFC3875 - The Common Gateway Interface (CGI) Version 1.1
- 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. National Centre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. This memo provides information for the Internet community.
- RFC3881 - Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications
- 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. This memo provides information for the Internet community.
- RFC3882 - Configuring BGP to Block Denial-of-Service Attacks
- 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. This memo provides information for the Internet community.
- RFC3884 - Use of IPsec Transport Mode for Dynamic Routing
- 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 the VN 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). This memo provides information for the Internet community.
- RFC3924 - Cisco Architecture for Lawful Intercept in IP Networks
- 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. This memo provides information for the Internet community.
- RFC3930 - The Protocol versus Document Points of View in Computer Protocols
- 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. This memo provides information for the Internet community.
- RFC3954 - Cisco Systems NetFlow Services Export Version 9
- This document specifies the data export format for version 9 of Cisco Systems' 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. This memo provides information for the Internet community.
- RFC3970 - A Traffic Engineering (TE) MIB
- 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. [STANDARDS-TRACK]
- RFC3974 - SMTP Operational Experience in Mixed IPv4/v6 Environments
- 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. This memo provides information for the Internet community.
- RFC3975 - OMA-IETF Standardization Collaboration
- This document describes the standardization collaboration between the Open Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.
- RFC3976 - Interworking SIP and Intelligent Network (IN) Applications
- 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 Session Initiation 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 the PSTN/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). This memo provides information for the Internet community.
- RFC3991 - Media Gateway Control Protocol (MGCP) Redirect and Reset Package
- The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) 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. This memo provides information for the Internet community.
- RFC3992 - Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism
- 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. This memo provides information for the Internet community.
- RFC4041 - Requirements for Morality Sections in Routing Area Drafts
- 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 Area Internet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain. This memo provides information for the Internet community.
- RFC4042 - UTF-9 and UTF-18 Efficient Transformation Formats of Unicode
- ISO-10646 defines a large character set called the Universal Character 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 to ISO/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. This memo provides information for the Internet community.
- RFC4050 - Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures
- This document specifies how to use Elliptic Curve Digital Signature Algorithm (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. This memo provides information for the Internet community.
- RFC4052 - IAB Processes for Management of IETF Liaison Relationships
- This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards 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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC4053 - Procedures for Handling Liaison Statements to and from the IETF
- 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. The IETF is only obligated to respond if there is an agreed liaison relationship, however. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC4089 - IAB and IESG Recommendation for IETF Administrative Restructuring
- This document describes a joint recommendation of the Internet Architecture 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. This memo provides information for the Internet community.
- RFC4101 - Writing Protocol Models
- 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. This memo provides information for the Internet community.
- RFC4115 - A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic
- 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 L2 VPN 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. This memo provides information for the Internet community.
- RFC4123 - Session Initiation Protocol (SIP)-H.323 Interworking Requirements
- 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 and H.323. This memo provides information for the Internet community.
- RFC4128 - Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation
- "Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, the Maximum 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. This memo provides information for the Internet community.
- RFC4144 - How to Gain Prominence and Influence in Standards Organizations
- This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations. This memo provides information for the Internet community.
- RFC4183 - A Suggested Scheme for DNS Resolution of Networks and Gateways
- 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. This memo provides information for the Internet community.
- RFC4185 - National and Local Characters for DNS Top Level Domain (TLD) Names
- 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. This memo provides information for the Internet community.
- RFC4212 - Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols
- The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet 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 Certificate Management Messages over CMS (CMC). This memo provides information for the Internet community.
- RFC4214 - Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
- The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 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. This memo defines an Experimental Protocol for the Internet community.
- RFC4241 - A Model of IPv6/IPv4 Dual Stack Internet Access Service
- This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/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 of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. This memo provides information for the Internet community.
- RFC4290 - Suggested Practices for Registration of Internationalized Domain Names (IDN)
- 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 for Chinese, Japanese, and Korean domain names. This memo provides information for the Internet community.
- RFC4316 - Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties
- This specification extends the Web Distributed Authoring and Versioning 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. This memo defines an Experimental Protocol for the Internet community.
- RFC4330 - Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
- This memorandum describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based on RFC 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) and SNTPv4 (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 of SNTP. This memo provides information for the Internet community.
- RFC4332 - Cisco's Mobile IPv4 Host Configuration Extensions
- 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 Configuration Protocol (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. This memo provides information for the Internet community.
- RFC4333 - The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process
- This memo outlines the guidelines for selection of members of the IETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
- RFC4367 - What's in a Name: False Assumptions about DNS Names
- The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform Resource Identifiers (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. This memo provides information for the Internet community.
- RFC4381 - Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)
- 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. This memo provides information for the Internet community.
- RFC4417 - Report of the 2004 IAB Messaging Workshop
- This document reports the outcome of a workshop held by the Internet Architecture 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. This memo provides information for the Internet community.
- RFC4440 - IAB Thoughts on the Role of the Internet Research Task Force (IRTF)
- 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 the IRTF. This memo provides information for the Internet community.
- RFC4441 - The IEEE 802/IETF Relationship
- Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, 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. This memo provides information for the Internet community.
- RFC4445 - A Proposed Media Delivery Index (MDI)
- 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. This memo provides information for the Internet community.
- RFC4463 - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks
- 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 further IETF 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 (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol). This memo provides information for the Internet community.
- RFC4498 - The Managed Object Aggregation MIB
- 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 Aggregation MIB 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 Managed Object instances. This memo defines an Experimental Protocol for the Internet community.
- RFC4503 - A Description of the Rabbit Stream Cipher Algorithm
- 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. This memo provides information for the Internet community.
- RFC4533 - The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation
- This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the Directory Information Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation. This memo defines an Experimental Protocol for the Internet community.
- RFC4540 - NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC4559 - SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows
- This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 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 And Protected Negotiate (SPNEGO) implementation are not provided in this document. This memo provides information for the Internet community.
- RFC4562 - MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network
- This document describes a mechanism to ensure layer-2 separation of Local Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.
- The mechanism - called "MAC-Forced Forwarding" - implements an Address Resolution Protocol (ARP) proxy function that prohibits Ethernet 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. This memo provides information for the Internet community.
- RFC4603 - Additional Values for the NAS-Port-Type Attribute
- This document defines a set of values for the NAS-Port-Type RADIUS Attribute. This memo provides information for the Internet community.
- RFC4651 - A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization
- This document describes and evaluates strategies to enhance Mobile IPv6 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. This memo provides information for the Internet community.
- RFC4678 - Server/Application State Protocol v1
- 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. The Server/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. This memo provides information for the Internet community.
- RFC4679 - DSL Forum Vendor-Specific RADIUS Attributes
- This document describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum.
- 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. This memo provides information for the Internet community.
- RFC4690 - Review and Recommendations for Internationalized Domain Names (IDNs)
- This note describes issues raised by the deployment and use of Internationalized 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 the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed. This memo provides information for the Internet community.
- RFC4691 - Guidelines for Acting as an IETF Liaison to Another Organization
- 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. This memo provides information for the Internet community.
- RFC4707 - Netnews Administration System (NAS)
- 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 of Usenet 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. This memo defines an Experimental Protocol for the Internet community.
- RFC4713 - Registration and Administration Recommendations for Chinese Domain Names
- 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 Traditional Chinese (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. This memo provides information for the Internet community.
- RFC4722 - Media Server Control Markup Language (MSCML) and Protocol
- 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. This memo provides information for the Internet community.
- RFC4732 - Internet Denial-of-Service Considerations
- 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. This memo provides information for the Internet community.
- RFC4763 - Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)
- 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. This memo provides information for the Internet community.
- RFC4764 - The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method
- This document specifies EAP-PSK, an Extensible Authentication Protocol (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. This memo defines an Experimental Protocol for the Internet community.
- RFC4777 - IBM's iSeries Telnet Enhancements
- This document describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allows Telnet 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 Telnet Environment option negotiation RFC 1572 to define new USERVAR variables that will be recognized by iSeries Telnet server. This memo provides information for the Internet community.
- RFC4784 - Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks
- 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 RADIUS Authentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA).
- cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA). This memo provides information for the Internet community.
- RFC4824 - The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)
- This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). This memo provides information for the Internet community.
- RFC4829 - Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering
- When the establishment of a higher priority (Traffic Engineering Label 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 which TE 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 TE LSPs (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. This memo provides information for the Internet community.
- RFC4838 - Delay-Tolerant Networking Architecture
- 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. This memo provides information for the Internet community.
- RFC4840 - Multiple Encapsulation Methods Considered Harmful
- This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods. This memo provides information for the Internet community.
- RFC4844 - The RFC Series and RFC Editor
- This document describes the framework for an RFC Series and an RFC Editor 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 RFC Series to continue to fulfill its mandate. This memo provides information for the Internet community.
- RFC4845 - Process for Publication of IAB RFCs
- 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. This memo provides information for the Internet community.
- RFC4846 - Independent Submissions to the RFC Editor
- 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. This memo provides information for the Internet community.
- RFC4876 - A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents
- 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. This memo provides information for the Internet community.
- RFC4903 - Multi-Link Subnet Issues
- 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. This memo provides information for the Internet community.
- RFC4907 - Architectural Implications of Link Indications
- 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. This memo provides information for the Internet community.
- RFC4908 - Multi-homing for small scale fixed network Using Mobile IP and NEMO
- 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. This memo defines an Experimental Protocol for the Internet community.
- RFC4924 - Reflections on Internet Transparency
- This document provides a review of previous IAB statements on Internet 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. This memo provides information for the Internet community.
- RFC4938 - PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
- This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with a credit-based flow control mechanism and Link Quality Metric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. This memo provides information for the Internet community.
- RFC4948 - Report from the IAB workshop on Unwanted Traffic March 9-10, 2006
- This document reports the outcome of a workshop held by the Internet Architecture 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. This memo provides information for the Internet community.
- RFC4949 - Internet Security Glossary, Version 2
- 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. This memo provides information for the Internet community.
- RFC4973 - OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering
- 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 Division Multiplexing (TDM) and optical networks. This memo defines an Experimental Protocol for the Internet community.
- RFC4981 - Survey of Research towards Robust Peer-to-Peer Networks: Search Methods
- 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. This memo provides information for the Internet community.
- RFC4984 - Report from the IAB Workshop on Routing and Addressing
- This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 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. This memo provides information for the Internet community.
- RFC5000 - Internet Official Protocol Standards
- This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, and Experimental 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. This memo provides information for the Internet community.
- RFC5022 - Media Server Control Markup Language (MSCML) and Protocol
- 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. This memo provides information for the Internet community.
- RFC5024 - ODETTE File Transfer Protocol 2.0
- 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 Message Syntax, 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 with TCP/IP, X.25, and ISDN-based networks. This memo provides information for the Internet community.
- RFC5050 - Bundle Protocol Specification
- 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 Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.
- RFC5058 - Explicit Multicast (Xcast) Concepts and Options
- 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 describes Xcast (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. This memo defines an Experimental Protocol for the Internet community.
- RFC5123 - Considerations in Validating the Path in BGP
- 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. This memo provides information for the Internet community.
- RFC5143 - Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation
- This document describes a historical method for encapsulating Synchronous 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. This memo defines a Historic Document for the Internet community.
- RFC5160 - Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)
- 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. This memo provides information for the Internet community.
- RFC5166 - Metrics for the Evaluation of Congestion Control Mechanisms
- 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 the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF 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. This memo provides information for the Internet community.
- RFC5171 - Cisco Systems UniDirectional Link Detection (UDLD) Protocol
- 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. This memo provides information for the Internet community.
- RFC5184 - Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover
- 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 the IP Mobility Optimizations (MobOpts) Research Group. This memo defines an Experimental Protocol for the Internet community.
- RFC5207 - NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication
- The Host Identity Protocol (HIP) changes the way in which two Internet 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. This memo provides information for the Internet community.
- RFC5211 - An Internet Transition Plan
- This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model. This memo provides information for the Internet community.
- RFC5214 - Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
- The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo provides information for the Internet community.
- RFC5218 - What Makes for a Successful Protocol?
- 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. This memo provides information for the Internet community.
- RFC5236 - Improved Packet Reordering Metrics
- 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. This memo provides information for the Internet community.
- RFC5241 - Naming Rights in IETF Protocols
- 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. This memo provides information for the Internet community.
- RFC5242 - A Generalized Unified Character Code: Western European and CJK Sections
- 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. This memo provides information for the Internet community.
- RFC5290 - Comments on the Usefulness of Simple Best-Effort Traffic
- This document presents some observations on "simple best-effort traffic", defined loosely for the purposes of this document as Internet 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. This memo provides information for the Internet community.
- RFC5320 - The Subnetwork Encapsulation and Adaptation Layer (SEAL)
- 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 diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. This document defines an Experimental Protocol for the Internet community.
- RFC5325 - Licklider Transmission Protocol - Motivation
- This document describes the motivation for the development of 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.
- 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 Automatic Repeat 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 Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.
- RFC5326 - Licklider Transmission Protocol - Specification
- 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 Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.
- RFC5327 - Licklider Transmission Protocol - Security Extensions
- 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 Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.
- RFC5345 - Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats
- 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 Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group. This memo provides information for the Internet community.
- RFC5379 - Guidelines for Using the Privacy Mechanism for SIP
- 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 and 4244. 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). This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5385 - Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs
- This document describes the properties and use of a revised Microsoft Word 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5402 - Compressed Data within an Internet Electronic Data Interchange (EDI) Message
- This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5412 - Lightweight Access Point Protocol
- 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 Access Points) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Lightweight Access Points). This specification defines the Lightweight Access Point Protocol (LWAPP), which addresses the CAPWAP'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. This document defines a Historic Document for the Internet community.
- RFC5413 - SLAPP: Secure Light Access Point Protocol
- 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 Access Controllers (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). This document defines a Historic Document for the Internet community.
- RFC5414 - Wireless LAN Control Protocol (WiCoP)
- 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 Wireless Access Points (CAPWAP). This document defines a Historic Document for the Internet community.
- RFC5456 - IAX: Inter-Asterisk eXchange Version 2
- 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 the Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice 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 around NAT, 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5457 - IANA Considerations for IAX: Inter-Asterisk eXchange Version 2
- 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 at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5505 - Principles of Internet Host Configuration
- 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. This memo provides information for the Internet community.
- RFC5507 - Design Choices When Expanding the DNS
- 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 DNS Resource Record Type is the best solution. This memo provides information for the Internet community.
- RFC5513 - IANA Considerations for Three Letter Acronyms
- 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 the Internet 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. This memo provides information for the Internet community.
- RFC5514 - IPv6 over Social Networks
- 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 IPv6 Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed. This memo defines an Experimental Protocol for the Internet community.
- RFC5517 - Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5540 - 40 Years of RFCs
- This RFC marks the 40th anniversary of the RFC document series. This memo provides information for the Internet community.
- RFC5544 - Syntax for Binding Documents with Time-Stamps
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5558 - Virtual Enterprise Traversal (VET)
- 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 provision IP 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5563 - WiMAX Forum / 3GPP2 Proxy Mobile IPv4
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5564 - Linguistic Guidelines for the Use of the Arabic Language in Internet Domains
- This document constitutes technical specifications for the use of Arabic 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5569 - IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
- IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5572 - IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)
- A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP 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. This document defines an Experimental Protocol for the Internet community.
- RFC5578 - PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5579 - Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces
- 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 automatic IPv6-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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5620 - RFC Editor Model (Version 1)
- The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, 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. This memo provides information for the Internet community.
- RFC5639 - Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation
- 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), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5683 - Password-Authenticated Key (PAK) Diffie-Hellman Exchange
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5684 - Unintended Consequences of NAT Deployments with Overlapping Address Space
- This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5690 - Adding Acknowledgement Congestion Control to TCP
- 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 the TCP data receiver. The TCP data sender detects lost or Explicit Congestion 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5694 - Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability
- 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. This memo provides information for the Internet community.
- RFC5704 - Uncoordinated Protocol Development Considered Harmful
- 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 on MPLS-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 IETF RFCs.
- 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. This memo provides information for the Internet community.
- RFC5707 - Media Server Markup Language (MSML)
- 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 using VoiceXMLThis document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5708 - X.509 Key and Signature Encoding for the KeyNote Trust Management System
- 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 or Licensees 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). This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5720 - Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)
- 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 a Mobile 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. The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5726 - Mobile IPv6 Location Privacy Solutions
- 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 Mobile IPv6 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 Mobility Optimizations (MobOpts) Research Group. This document defines an Experimental Protocol for the Internet community.
- RFC5741 - RFC Streams, Headers, and Boilerplates
- RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5743 - Definition of an Internet Research Task Force (IRTF) Document Stream
- This memo defines the publication stream for RFCs from the Internet Research 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5744 - Procedures for Rights Handling in the RFC Independent Submission Stream
- This document specifies the procedures by which authors of RFC Independent 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. This memo provides information for the Internet community.
- RFC5745 - Procedures for Rights Handling in the RFC IAB Stream
- This document specifies the procedures by which authors of RFC IAB stream 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. This memo provides information for the Internet community.
- RFC5747 - 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC5757 - Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey
- 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 and Source-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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5765 - Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications
- 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 P2P Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5772 - A Set of Possible Requirements for a Future Routing Architecture
- 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 the Internet 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. This document defines a Historic Document for the Internet community.
- RFC5773 - Analysis of Inter-Domain Routing Requirements and History
- 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. This document defines a Historic Document for the Internet community.
- RFC5782 - DNS Blacklists and Whitelists
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5783 - Congestion Control in the RFC Series
- This document is an informational snapshot taken by the IRTF\'s Internet 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5794 - A Description of the ARIA Encryption Algorithm
- This document describes the ARIA encryption algorithm. ARIA is a 128-bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of a key scheduling part and data randomizing part. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5805 - Lightweight Directory Access Protocol (LDAP) Transactions
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC5806 - Diversion Indication in SIP
- 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 later Informational RFCs. The original Abstract follows.
- This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP 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 Automatic Call Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions. This document defines a Historic Document for the Internet community.
- RFC5830 - GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms
- This document is intended to be a source of information about the Russian 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 in Internet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5831 - GOST R 34.11-94: Hash Function Algorithm
- This document is intended to be a source of information about the Russian 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 in Internet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5832 - GOST R 34.10-2001: Digital Signature Algorithm
- This document is intended to be a source of information about the Russian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet 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.
- RFC5841 - TCP Option to Denote Packet Mood
- This document proposes a new TCP option to denote packet mood. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5861 - HTTP Cache-Control Extensions for Stale Content
- This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5895 - Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
- In the original version of the Internationalized Domain Names in Applications (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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5902 - IAB Thoughts on IPv6 Network Address Translation
- There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC5984 - Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding
- This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding. This document defines an Experimental Protocol for the Internet community.
- RFC5992 - Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6013 - TCP Cookie Transactions (TCPCT)
- TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks. This document defines an Experimental Protocol for the Internet community.
- RFC6017 - Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field
- With the maturity of the Electronic Data Interchange - Internet Integration (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 all EDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6023 - A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)
- 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. This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
- RFC6029 - A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6037 - Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs
- 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 generalized MVPN 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. This document defines a Historic Document for the Internet community.
- RFC6042 - Transport Layer Security (TLS) Authorization Using KeyNote
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6044 - Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)
- Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.
- This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.
- Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6055 - IAB Thoughts on Encodings for Internationalized Domain Names
- This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-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.
- RFC6077 - Open Research Issues in Internet Congestion Control
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6108 - Comcast's Web Notification System Design
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6114 - The 128-Bit Blockcipher CLEFIA
- This document describes the specification of the blockcipher CLEFIA. CLEFIA is a 128-bit blockcipher, with key lengths of 128, 192, and 256 bits, which is compatible with the interface of the Advanced Encryption Standard (AES). The algorithm of CLEFIA was published in 2007, 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 the Internet, which will be connected to more distributed and constrained devices. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6115 - Recommendation for a Routing Architecture
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6126 - The Babel Routing Protocol
- Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document defines an Experimental Protocol for the Internet community.
- RFC6137 - The Network Trouble Ticket Data Model (NTTDM)
- 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. The TT systems of the participants collect, represent, and disseminate TT information in different formats.
- As a result, management of the daily workload by a central Network Operation Centre (NOC) is a challenge on its own. Normalization of TTs 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. This document defines an Experimental Protocol for the Internet community.
- RFC6139 - Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios
- "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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6159 - Session-Specific Explicit Diameter Request Routing
- This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6179 - The Internet Routing Overlay Network (IRON)
- 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 an Internet 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 the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
- RFC6193 - Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)
- This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6214 - Adaptation of RFC 1149 for IPv6
- This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6217 - Regional Broadcast Using an Atmospheric Link Layer
- 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 Area Networks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6218 - Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6220 - Defining the Role and Function of IETF Protocol Parameter Registry Operators
- 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 is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6227 - Design Goals for Scalable Internet Routing
- 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 Research Group is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6250 - Evolution of the IP Model
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6252 - A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6255 - Delay-Tolerant Networking Bundle Protocol IANA Registries
- The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and Licklider Transmission 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 to IANA for official custody. This document describes the actions executed by IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6256 - Using Self-Delimiting Numeric Values in Protocols
- 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 the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6257 - Bundle Security Protocol Specification
- 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 Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.
- RFC6258 - Delay-Tolerant Networking Metadata Extension Block
- This document defines an extension block that may be used with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Metadata Extension 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 an RFC were raised. This document defines an Experimental Protocol for the Internet community.
- RFC6259 - Delay-Tolerant Networking Previous-Hop Insertion Block
- This document defines an extension block for use with the Delay- Tolerant Networking (DTN) Bundle Protocol. This Previous-Hop Insertion 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. This document defines an Experimental Protocol for the Internet community.
- RFC6260 - Compressed Bundle Header Encoding (CBHE)
- This document describes a convention by which Delay-Tolerant Networking (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 different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC6294 - Survey of Proposed Use Cases for the IPv6 Flow Label
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6306 - Hierarchical IPv4 Framework
- 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 Domain Name 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. This document defines an Experimental Protocol for the Internet community.
- RFC6386 - VP8 Data Format and Decoding Guide
- This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6417 - How to Contribute Research Results to Internet Standardization
- 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 the Internet 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6431 - Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6462 - Report from the Internet Privacy Workshop
- 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 Intelligence Laboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protective Internet 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6471 - Overview of Best Email DNS-Based List (DNSBL) Operational Practices
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6479 - IPsec Anti-Replay Algorithm without Bit Shifting
- This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6529 - Host/Host Protocol for the ARPA Network
- This document reproduces the Host/Host Protocol developed by the ARPA Network 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 the ARPA Network from January 1972 until the switch to TCP/IP in January 1983. It is offered as an RFC at this late date to help complete the historical record available through the RFC series. This document is not an Internet Standards Track specification; it is published for the historical record.
- RFC6537 - Host Identity Protocol Distributed Hash Table Interface
- This document specifies a common interface for using the Host Identity 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. This document defines an Experimental Protocol for the Internet community.
- RFC6538 - The Host Identity Protocol (HIP) Experiment Report
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6539 - IBAKE: Identity-Based Authenticated Key Exchange
- 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 of Identity-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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6548 - Independent Submission Editor Model
- This document describes the function and responsibilities of the RFC Independent 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 Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administrative Oversight Committee (IAOC). This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6574 - Report from the Smart Object Workshop
- This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. 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 Engineering Task 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6592 - The Null Packet
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6593 - Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS)
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC6635 - RFC Editor Model (Version 2)
- The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620, and obsoletes that document. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6653 - DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks
- 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 Prefix Delegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to a DHCPv6 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6654 - Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)
- This document proposes an alternative IPv6 Rapid Deployment on IPv4 Infrastructures (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's IPv4 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6687 - Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)
- This document presents a performance evaluation of the Routing Protocol 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6693 - Probabilistic Routing Protocol for Intermittently Connected Networks
- 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.
- This document defines PRoPHET, a Probabilistic Routing Protocol using History 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. This document defines an Experimental Protocol for the Internet community.
- RFC6709 - Design Considerations for Protocol Extensions
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6717 - kx509 Kerberized Certificate Issuance Protocol in Use in 2012
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6732 - 6to4 Provider Managed Tunnels
- 6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The 6to4-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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6740 - Identifier-Locator Network Protocol (ILNP) Architectural Description
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC6741 - Identifier-Locator Network Protocol (ILNP) Engineering Considerations
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC6742 - DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC6743 - ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
- This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network 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 IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
- RFC6744 - IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
- 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 the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
- RFC6745 - ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
- 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 IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.
- RFC6746 - IPv4 Options for the Identifier-Locator Network Protocol (ILNP)
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC6747 - Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC6748 - Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)
- This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-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 of ILNP-based systems. This document defines an Experimental Protocol for the Internet community.
- RFC6751 - Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC6756 - Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines
- This document provides guidance to aid in the understanding of collaboration on standards development between the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Internet Engineering Task Force (IETF) of the Internet 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 A Series Supplement 3 (07/2012).
- Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to the ITU-T A-Series of Recommendations.
- This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6804 - DISCOVER: Supporting Multicast DNS Queries
- 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 the DISCOVER opcode and processes the multiple responses that may result. This document defines a Historic Document for the Internet community.
- RFC6812 - Cisco Service-Level Assurance Protocol
- Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is a Performance 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6821 - Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality
- 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 Research Group).
- RFC6837 - NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database
- 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. This document defines an Experimental Protocol for the Internet community.
- RFC6847 - Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL)
- Fibre Channel over Ethernet (FCoE) and Transparent Interconnection of Lots 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 Media Access Control (MAC) addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6852 - Affirmation of the Modern Paradigm for Standards
- On 29 August 2012, the leaders of the IEEE Standards Association, the IAB, 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6861 - The "create-form" and "edit-form" Link Relations
- 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. This document is not an Internet Standards Track specification; it is published for informational purposes.
- RFC6875 - The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan
- 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 the ALTO architecture and especially for application-independent ALTO- like server operation.
- RFC6886 - NAT Port Mapping Protocol (NAT-PMP)
- 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.
- RFC6892 - The 'describes' Link Relation Type
- 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.
- RFC6896 - SCS: KoanLogic's Secure Cookie Sessions for HTTP
- 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 via HTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, Home Office (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.
- RFC6903 - Additional Link Relation Types
- This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.
- RFC6906 - The 'profile' Link Relation Type
- 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.
- RFC6912 - Principles for Unicode Code Point Inclusion in Labels in the DNS
- 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 of U-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.
- RFC6919 - Further Key Words for Use in RFCs to Indicate Requirement Levels
- 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.
- RFC6921 - Design Considerations for Faster-Than-Light (FTL) Communication
- 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.
- RFC6927 - Variants in Second-Level Names Registered in Top-Level Domains
- 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 the IETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA.
- RFC6943 - Issues in Identifier Comparison for Security Purposes
- 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.
- RFC6947 - The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute
- 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 Network Address 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 RFC 5245, provides such a solution.
- RFC6948 - Some Measurements on World IPv6 Day from an End-User Perspective
- 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.
- RFC6949 - RFC Series Format Requirements and Future Development
- 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.
- RFC6950 - Architectural Considerations on Application Features in the DNS
- 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.
- RFC6964 - Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
- Many end-user sites in the Internet today still have predominantly IPv4 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 the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
- RFC6973 - Privacy Considerations for Internet Protocols
- 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.
- RFC6978 - A TCP Authentication Option Extension for NAT Traversal
- This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through Network Address Translators and/or Network Address and Port Translators (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.
- RFC6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
- This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (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.
- RFC6983 - Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)
- This document presents thoughts on the potential impact of supporting HTTP Adaptive Streaming (HAS) technologies in Content Distribution Network 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 for HAS.
- RFC6986 - GOST R 34.11-2012: Hash Function
- This document is intended to be a source of information about the Russian 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.
- RFC7008 - A Description of the KCipher-2 Encryption Algorithm
- 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.
- RFC7019 - Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD)
- We define a REsource LOcation And Discovery (RELOAD) Usage for Application-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 Multicast Research Group (SAM RG).
- RFC7021 - Assessing the Impact of Carrier-Grade NAT on Network Applications
- NAT444 is an IPv4 extension technology being considered by Service Providers 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 common Internet applications. This document was updated to include the Dual-Stack Lite (DS-Lite) impacts also.
- RFC7046 - A Common API for Transparent Hybrid Multicast
- 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 Multicast Domains 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.
- RFC7047 - The Open vSwitch Database Management Protocol
- 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.
- RFC7059 - A Comparison of IPv6-over-IPv4 Tunnel Mechanisms
- 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.
- RFC7061 - eXtensible Access Control Markup Language (XACML) XML Media Type
- This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML).
- RFC7069 - DECoupled Application Data Enroute (DECADE)
- 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.
- RFC7076 - P6R's Secure Shell Public Key Subsystem
- 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 Management Interoperability 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.
- RFC7085 - Top-Level Domains That Are Already Dotless
- Recent statements from the Internet Architecture Board (IAB) and the Internet 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.
- RFC7089 - HTTP Framework for Time-Based Access to Resource States -- Memento
- 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.
- RFC7091 - GOST R 34.10-2012: Digital Signature Algorithm
- This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of the Russian 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.
- RFC7093 - Additional Methods for Generating Key Identifiers Values
- This document specifies additional example methods for generating Key Identifier values for use in the AKI (Authority Key Identifier) and SKI (Subject Key Identifier) certificate extensions.
- RFC7094 - Architectural Considerations of IP Anycast
- This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.
- RFC7101 - List of Internet Official Protocol Standards: Replaced by a Web Page
- At one time, the RFC Editor published snapshots of the "Internet Official 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 RFC Editor will classify unpublished RFC xx00 numbers through 7000 as never issued. Starting with the RFC number 7100, xx00 numbers will be available for assignment.
- RFC7108 - A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes
- 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.
- RFC7109 - Flow Bindings Initiated by Home Agents for Mobile IPv6
- 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.
- RFC7111 - URI Fragment Identifiers for the text/csv Media Type
- 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.
- RFC7116 - Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries
- The DTNRG Research Group has defined the experimental Licklider Transmission 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.
- RFC7122 - Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)
- This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle 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 the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.
- RFC7129 - Authenticated Denial of Existence in the DNS
- 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 DNS Security 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.
- RFC7168 - The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)
- 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.
- RFC7169 - The NSA (No Secrecy Afforded) Certificate Extension
- This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic Key Certificates) 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.
- RFC7194 - Default Port for Internet Relay Chat (IRC) via TLS/SSL
- This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL.
- RFC7241 - The IEEE 802/IETF Relationship
- This document describes the standardization cooperation between Project 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.
- RFC7242 - Delay-Tolerant Networking TCP Convergence-Layer Protocol
- This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of the IRTF's DTN Research Group (DTNRG).
- RFC7253 - The OCB Authenticated-Encryption Algorithm
- 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).
- RFC7259 - The Jabber-ID Header Field
- 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 particular Extensible Messaging and Presence Protocol (XMPP) address.
- RFC7281 - Authentication-Results Registration for S/MIME Signature Verification
- 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.
- RFC7284 - The Profile URI Registry
- This document defines a registry for profile URIs to be used in specifications standardizing profiles.
- RFC7288 - Reflections on Host Firewalls
- 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.
- RFC7295 - Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication
- 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 Internet Engineering 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 the Internet Research Task Force (IRTF).
- RFC7297 - IP Connectivity Provisioning Profile (CPP)
- 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 of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs.
- RFC7298 - Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication
- This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.
- RFC7304 - A Method for Mitigating Namespace Collisions
- 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.
- RFC7305 - Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)
- This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Internet Technology Adoption and Transition (ITAT). The workshop was hosted by the University of Cambridge 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.
- RFC7314 - Extension Mechanisms for DNS (EDNS) EXPIRE Option
- 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.
- RFC7322 - RFC Style Guide
- 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".
- RFC7328 - Writing I-Ds and RFCs Using Pandoc and a Bit of XML
- 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) or RFCs.
- 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.
- RFC7342 - Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers
- This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments.
- RFC7347 - Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP)
- 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-TP Linear 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.
- RFC7348 - Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks
- 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.
- RFC7351 - A Media Type for XML Patch Operations
- 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.
- RFC7393 - Using the Port Control Protocol (PCP) to Update Dynamic DNS
- This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo.
- RFC7397 - Report from the Smart Object Security Workshop
- This document provides a summary of a workshop on 'Smart Object Security' 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.
- RFC7418 - An IRTF Primer for IETF Participants
- This document provides a high-level description of things for Internet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the Internet Research Task Force (IRTF). This document emphasizes differences in expectations between the two organizations.
- RFC7422 - Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments
- 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.
- RFC7425 - Adobe's RTMFP Profile for Flash Communication
- This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe 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.
- RFC7426 - Software-Defined Networking (SDN): Layers and Architecture Terminology
- 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 Research Group (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.
- RFC7444 - Security Labels in Internet Email
- This document describes a header field, SIO-Label, for use in Internet 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.
- RFC7452 - Architectural Considerations in Smart Object Networking
- The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet 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.
- RFC7476 - Information-Centric Networking: Baseline Scenarios
- 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 Networking Research Group (ICNRG).
- RFC7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- 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.
- RFC7500 - Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries
- This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.
- RFC7508 - Securing Header Fields with S/MIME
- 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'.
- RFC7511 - Scenic Routing for IPv6
- This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "Green IT", whereby packets will be routed to get as much fresh-air time as possible.
- RFC7514 - Really Explicit Congestion Notification (RECN)
- 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 and Explicit Congestion Notification (ECN).
- RFC7539 - ChaCha20 and Poly1305 for IETF Protocols
- This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.
- This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG).
- RFC7544 - Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP)
- 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.
- RFC7557 - Extension Mechanism for the Babel Routing Protocol
- This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.
- RFC7562 - Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates
- This document specifies the use of Digital Transmission Content Protection (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 containing DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA).
- RFC7566 - Enumservice Registration for 'acct' URI
- This document registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers).
- RFC7575 - Autonomic Networking: Definitions and Design Goals
- 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 Autonomic Network interact. This document is a product of the IRTF's Network Management Research Group.
- RFC7576 - General Gap Analysis for Autonomic Networking
- 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 Research Group.
- RFC7586 - The Scalable Address Resolution Protocol (SARP) for Large Data Centers
- 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.
- RFC7593 - The eduroam Architecture for Network Roaming
- This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination of IEEE 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.
- RFC7609 - IBM's Shared Memory Communications over RDMA (SMC-R) Protocol
- 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.
- RFC7612 - Lightweight Directory Access Protocol (LDAP): Schema for Printer Services
- This document defines a schema, object classes, and attributes, for Printers 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 "Internet Printing Protocol/1.1: Model and Semantics" (RFC 2911). Additional Printer attributes are based on definitions in "Printer MIB v2" (RFC 3805), "PWG Command Set Format for IEEE 1284 Device ID v1.0" (PWG 5107.2), "IPP Job and Printer Extensions - Set 3 (JPS3)" (PWG 5100.13), and "IPP Everywhere" (PWG 5100.14).
- This memo is an Independent Submission to the RFC Editor by the Internet Printing Protocol (IPP) Working Group of the IEEE-ISTO Printer Working Group (PWG), as part of their PWG "IPP Everywhere" (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software.
- This document obsoletes RFC 3712.
- RFC7620 - Scenarios with Host Identification Complications
- 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.
- RFC7624 - Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement
- 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.
- RFC7625 - Architecture of an IP/MPLS Network with Hardened Pipes
- 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 Label Switched 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 the LSPs 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.
- RFC7637 - NVGRE: Network Virtualization Using Generic Routing Encapsulation
- This document describes the usage of the Generic Routing Encapsulation (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.
- RFC7649 - The Jabber Scribe Role at IETF Meetings
- 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.
- RFC7651 - 3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2)
- This document defines two new configuration attributes for the Internet Key Exchange Protocol version 2 (IKEv2). These attributes can be used for carrying the IPv4 address and IPv6 address of the Proxy-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.
- RFC7663 - Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)
- The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox Internet (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.
- RFC7664 - Dragonfly Key Exchange
- 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 Forum Research Group (CFRG).
- RFC7669 - Assigning Digital Object Identifiers to RFCs
- 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.
- RFC7681 - Email Exchange of Secondary School Transcripts
- 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.
- RFC7687 - Report from the Strengthening the Internet (STRINT) Workshop
- 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.
- RFC7693 - The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)
- 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).
- RFC7703 - Experience with Testing of Mapping of Address and Port Using Translation (MAP-T)
- This document describes the testing result of a network utilizing a Mapping 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.
- RFC7704 - An IETF with Much Diversity and Professional Conduct
- 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.
- RFC7745 - XML Schemas for Reverse DNS Management
- This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational State Transfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an HTTPS transaction that is mediated by an X.509 certificate.
- RFC7748 - Elliptic Curves for Security
- 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.
- RFC7749 - The "xml2rfc" Version 2 Vocabulary
- This document defines the "xml2rfc" version 2 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts.
- Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014.
- This document obsoletes RFC 2629.
- RFC7754 - Technical Considerations for Internet Service Blocking and Filtering
- 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 the Internet 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.
- RFC7767 - Application-Initiated Check-Pointing via the Port Control Protocol (PCP)
- This document specifies a mechanism for a host to indicate via the Port 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.
- RFC7768 - Port Management to Reduce Logging in Large-Scale NATs
- 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.
- RFC7785 - Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite
- 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.
- RFC7801 - GOST R 34.12-2015: Block Cipher "Kuznyechik"
- This document is intended to be a source of information about the Russian 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 (called GOST algorithms).
- RFC7827 - The Role of the IRTF Chair
- This document briefly describes the role of the Chair of the Internet Research Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have.
- RFC7836 - Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012
- The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST 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.
- RFC7841 - RFC Streams, Headers, and Boilerplates
- RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats.
- RFC7849 - An IPv6 Profile for 3GPP Mobile Devices
- This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership 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 Partnership Project (3GPP) Cellular Hosts" (RFC 7066).
- Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope.
- RFC7868 - Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)
- This document describes the protocol design and architecture for Enhanced 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.
- RFC7869 - The "vnc" URI Scheme
- 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.
- RFC7903 - Windows Image Media Types
- 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.
- RFC7906 - NSA's Cryptographic Message Syntax (CMS) Key Management Attributes
- This document defines key management attributes used by the National Security Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (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.
- RFC7910 - Interoperability between the Virtual Router Redundancy Protocol and PIM
- This document introduces VRRP-aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with the Virtual Router Redundancy Protocol (VRRP). It allows PIM to track VRRP 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.
- RFC7912 - Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure
- This document describes a procedure for when a Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more Authorizing Users authorize release of the message by adding the MMHS-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.
- RFC7927 - Information-Centric Networking (ICN) Research Challenges
- This memo describes research challenges for Information-Centric Networking (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 Networking Research Group (ICNRG).
- RFC7933 - Adaptive Video Streaming over Information-Centric Networking (ICN)
- 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 Experts Group (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.
- RFC7943 - A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
- This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol 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 Address Autoconfiguration.
- RFC7945 - Information-Centric Networking: Evaluation and Security Considerations
- 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.
- RFC7958 - DNSSEC Trust Anchor Publication for the Root Zone
- 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 using DNSSEC, 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.
- RFC7962 - Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures
- This document presents a taxonomy of a set of "Alternative Network Deployments" that emerged in the last decade with the aim of bringing Internet 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.
- RFC7967 - Constrained Application Protocol (CoAP) Option for No Server Response
- 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 the No-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.
- RFC7974 - An Experimental TCP Option for Host Identification
- 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 the Internet today that uses a TCP option to transmit a host identifier.
- RFC7980 - A Framework for Defining Network Complexity
- 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 Complexity Research 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.
- RFC7990 - RFC Format Framework
- 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 version 3 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.
- RFC7991 - The "xml2rfc" Version 3 Vocabulary
- This document defines the "xml2rfc" version 3 vocabulary: an XML-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 in RFC 7749.
- RFC7992 - HTML Format for RFCs
- 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.
- RFC7993 - Cascading Style Sheets (CSS) Requirements for RFCs
- The HTML format for RFCs assigns style guidance to a Cascading Style Sheet (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).
- RFC7994 - Requirements for Plain-Text RFCs
- In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs 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.
- RFC7995 - PDF Format for RFCs
- 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.
- RFC7996 - SVG Drawings for RFCs: SVG 1.2 RFC
- 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.
- RFC7997 - The Use of Non-ASCII Characters in RFCs
- 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.
- RFC7998 - "xml2rfc" Version 3 Preparation Tool Description
- This document describes some aspects of the "prep tool" that is expected to be created when the new xml2rfc version 3 specification is deployed.
- RFC8023 - Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions
- This document provides context and a report on the workshop on "Root Causes and Mitigation of Name Collisions", which took place in London, 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.
- RFC8032 - Edwards-Curve Digital Signature Algorithm (EdDSA)
- This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
- RFC8043 - Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space
- 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.
- RFC8073 - Coordinating Attack Response at Internet Scale (CARIS) Workshop Report
- This report documents the discussions and conclusions from the Coordinating 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.
- RFC8090 - Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG)
- 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.
- RFC8112 - Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG)
- A simple tool called the Locator/ID Separation Protocol Delegated Database 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.
- RFC8125 - Requirements for Password-Authenticated Key Agreement (PAKE) Schemes
- 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).
- RFC8128 - IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee
- This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).
- RFC8133 - The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol
- 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.
- RFC8135 - Complex Addressing in IPv6
- 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.
- RFC8136 - Additional Transition Functionality for IPv6
- This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.
- RFC8140 - The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character
- 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 Trade Mark, 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.
- RFC8153 - Digital Preservation Considerations for the RFC Series
- The RFC Editor is both the publisher and the archivist for the RFC Series. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserve RFCs 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.
- RFC8157 - Huawei's GRE Tunnel Bonding Protocol
- There is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single Service Provider, 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 Tunnel Bonding, 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.
- RFC8170 - Planning for Protocol Adoption and Subsequent Transitions
- 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.
- RFC8216 - HTTP Live Streaming
- 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.
- RFC8235 - Schnorr Non-interactive Zero-Knowledge Proof
- 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 Schnorr NIZK proof in both the finite field and the elliptic curve settings.
- RFC8236 - J-PAKE: Password-Authenticated Key Exchange by Juggling
- This document specifies a Password-Authenticated Key Exchange by Juggling (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.
- RFC8240 - Report from the Internet of Things Software Update (IoTSU) Workshop 2016
- This document provides a summary of the Internet of Things Software Update (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.
- RFC8272 - TinyIPFIX for Smart Meters in Constrained Networks
- 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.
- RFC8280 - Research into Human Rights Protocol Considerations
- 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 Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group.
- RFC8316 - Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations
- 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 Research Group (NMRG). It is published for informational purposes.
- RFC8324 - DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?
- 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.
- RFC8328 - Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA)
- 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.
- RFC8351 - The PKCS #8 EncryptedPrivateKeyInfo Media Type
- 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.
- RFC8367 - Wrongful Termination of Internet Protocol (IP) Packets
- 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.
- RFC8369 - Internationalizing IPv6 Using 128-Bit Unicode
- It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed. Assuming ISO and the Unicode Consortium follow the practices of the IETF, the next Unicode code point size will be 128 bits. This document describes how this future 128-bit Unicode can be leveraged to improve IPv6 adoption and finally bring internationalization support to IPv6.
- RFC8374 - BGPsec Design Choices and Summary of Supporting Discussions
- 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 IETF SIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes.
- RFC8391 - XMSS: eXtended Merkle Signature Scheme
- 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 specifies Winternitz 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.
- RFC8406 - Taxonomy of Coding Techniques for Efficient Network Communications
- 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 on Network Coding. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG), and it is in line with the terminology used by the RFCs produced by the Reliable Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups.
- RFC8409 - The Entity Category Security Assertion Markup Language (SAML) Attribute Types
- 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 the Research and Education FEDerations (REFEDS) group.
- RFC8433 - A Simpler Method for Resolving Alert-Info URNs
- 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 the URNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace.
- RFC8439 - ChaCha20 and Poly1305 for IETF Protocols
- This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.
- 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 Security Considerations section.
- RFC8452 - AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
- 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.
- RFC8462 - Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)
- 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 Content Delivery 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.
- RFC8477 - Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
- This document provides a summary of the "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)", which took place in Santa 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.
- RFC8479 - Storing Validation Parameters in PKCS#8
- This memo describes a method of storing parameters needed for private-key validation in the Private-Key Information Syntax Specification as defined in PKCS#8 format (RFC 5208). It is equally applicable to the alternative implementation of the Private-Key Information 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.
- RFC8483 - Yeti DNS Testbed
- 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's Domain Name System is designed and built).
- RFC8492 - Secure Password Ciphersuites for Transport Layer Security (TLS)
- This memo defines several new ciphersuites for the Transport Layer Security (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.
- RFC8493 - The BagIt File Packaging Format (V1.0)
- 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.
- RFC8494 - Multicast Email (MULE) over Allied Communications Publication (ACP) 142
- 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 (Multicast Email), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP 142). 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.
- RFC8507 - Simple Internet Protocol (SIP) Specification
- This document is published for the historical record. The Simple Internet Protocol was the basis for one of the candidates for the IETF'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 Simple Internet 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.
- RFC8517 - An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective
- 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 the Internet. 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.
- RFC8522 - Looking Glass Command Set
- 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.
- RFC8546 - The Wire Image of a Network Protocol
- 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.
- RFC8554 - Leighton-Micali Hash-Based Signatures
- 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 in 1995. 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.
- RFC8558 - Transport Protocol Path Signals
- 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.
- RFC8565 - Hypertext Jeopardy Protocol (HTJP/1.0)
- 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.
- RFC8567 - Customer Management DNS Resource Records
- Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed Customer Premises 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.
- RFC8568 - Network Virtualization Research Challenges
- 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 Virtualization Research Group (NFVRG).
- RFC8569 - Content-Centric Networking (CCNx) Semantics
- This document describes the core concepts of the Content-Centric Networking (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 Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.
- RFC8574 - cite-as: A Link Relation to Convey a Preferred URI for Referencing
- 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.
- RFC8576 - Internet of Things (IoT) Security: State of the Art and Challenges
- The Internet of Things (IoT) concept refers to the usage of standard Internet 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 Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (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 secure IoT 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).
- RFC8592 - Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH)
- This document describes methods of carrying Key Performance Indicators (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.
- RFC8597 - Cooperating Layered Architecture for Software-Defined Networking (CLAS)
- 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 Layered Architecture 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.
- RFC8603 - Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile
- This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. 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.
- RFC8604 - Interconnecting Millions of Endpoints with Segment Routing
- 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.
- RFC8609 - Content-Centric Networking (CCNx) Messages in TLV Format
- 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 a TLV 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 among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.
- RFC8645 - Re-keying Mechanisms for Symmetric Keys
- 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.
- RFC8672 - TLS Server Identity Pinning with Tickets
- 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.
- RFC8674 - The "safe" HTTP Preference
- 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.
- RFC8677 - Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework
- 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 Service Function 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 different IP 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 the SFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers.
- RFC8700 - Fifty Years of RFCs
- 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.
- RFC8720 - Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries
- This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.
- RFC8722 - Defining the Role and Function of IETF Protocol Parameter Registry Operators
- 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.
- RFC8726 - How Requests for IANA Action Will Be Handled on the Independent Stream
- The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF 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 the Independent Submissions Editor (ISE).
- This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent Submission Stream 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.
- RFC8728 - RFC Editor Model (Version 2)
- The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and the RSOC. This document reflects the experience gained with "RFC Editor Model (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.0 Model.
- RFC8729 - The RFC Series and RFC Editor
- This document describes the framework for an RFC Series and an RFC Editor 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 RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844.
- RFC8730 - Independent Submission Editor Model
- This document describes the function and responsibilities of the RFC Independent 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 Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administration Limited Liability Company (LLC).
- This version obsoletes RFC 6548 to replace all references to the Internet Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 structure.
- RFC8734 - Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3
- 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 TLS 1.3.
- This document provides the necessary protocol mechanisms for using ECC Brainpool curves in TLS 1.3. This approach is not endorsed by the IETF.
- RFC8743 - Multiple Access Management Services Multi-Access Management Services (MAMS)
- 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.
- RFC8752 - Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)
- The Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture Board (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.
- RFC8755 - Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions
- The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 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.
- RFC8756 - Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS
- This document specifies a profile of the Certificate Management over CMS (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.
- RFC8763 - Deployment Considerations for Information-Centric Networking (ICN)
- 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-Centric Networking Research Group (ICNRG).
- RFC8764 - Apple's DNS Long-Lived Queries Protocol
- Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, 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 the LLQ 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 Push Notifications.
- RFC8771 - The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO)
- 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 the Internationalized 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.
- RFC8772 - The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP)
- 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 simple CUPS control channel protocol to support such communication: the Simple 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.
- RFC8774 - The Quantum Bug
- 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 some Internet 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.
- RFC8785 - JSON Canonicalization Scheme (JCS)
- 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 of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting.
- RFC8793 - Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology
- 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 Data Networking (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 other ICN 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).
- RFC8799 - Limited Domains and Internet Protocols
- 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.
- RFC8802 - The Quality for Service (Q4S) Protocol
- This memo describes an application-level protocol for the communication of end-to-end QoS compliance information based on the HyperText Transfer Protocol (HTTP) and the Session Description Protocol (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.
- RFC8805 - A Format for Self-Published IP Geolocation Feeds
- 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.
- RFC8884 - Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios
- 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 Research Group (ICNRG).
- RFC8890 - The Internet is for End Users
- 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.
- RFC8891 - GOST R 34.12-2015: Block Cipher "Magma"
- In addition to a new cipher with a block length of n=128 bits (referred to as "Kuznyechik" and described in RFC 7801), Russian Federal 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 in Internet 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.
- RFC8902 - TLS Authentication Using Intelligent Transport System (ITS) Certificates
- 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.
- RFC8904 - DNS Whitelist (DNSWL) Email Authentication Method Extension
- This document describes an email authentication method compliant with RFC 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.
- RFC8905 - The 'payto' URI Scheme for Payments
- 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.
- RFC8921 - Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP)
- This document defines the Connectivity Provisioning Negotiation Protocol (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, Content Delivery Networks, etc.
- RFC8927 - JSON Type Definition
- 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.
- RFC8937 - Randomness Improvements for Security Protocols
- 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.
- RFC8953 - Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report
- The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop, sponsored by the Internet Society, took place on 28 February 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.
- RFC8962 - Establishing the Protocol Police
- 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 the Protocol Police.
- RFC8963 - Evaluation of a Sample of RFCs Produced in 2018
- This document presents the author's effort to understand the delays involved in publishing an idea in the IETF or through the Independent Stream, from the first individual draft to the publication of the RFC. 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 using Semantic 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.
- RFC8975 - Network Coding for Satellite Systems
- This document is a product of the Coding for Efficient Network Communications 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 Network Coding 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.
- RFC8980 - Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development
- The Design Expectations vs. Deployment Reality in Protocol Development 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.
- RFC8998 - ShangMi (SM) Cipher Suites for TLS 1.3
- 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.
- RFC9021 - Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE)
- This document specifies the conventions for using the Walnut Digital Signature Algorithm (WalnutDSA) for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax. WalnutDSA is a lightweight, quantum-resistant signature scheme based on Group Theoretic 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 of WalnutDSA 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.
- RFC9049 - Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)
- This document is a product of the Path Aware Networking Research Group (PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for Path Aware networking researchers.
- This document contains that catalog and analysis.
- RFC9057 - Email Author Header Field
- 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 by Mediators. This document is published as an Experimental RFC to assess community interest, functional efficacy, and technical adequacy.
- RFC9058 - Multilinear Galois Mode (MGM)
- Multilinear Galois Mode (MGM) is an Authenticated Encryption with Associated 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 and IPsec. 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.
- RFC9064 - Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols
- 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 of Quality 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-Centric Networking Research Group (ICNRG) but has been through formal Last Call and has the support of the participants in the research group for publication as an individual submission.
- RFC9075 - Report from the IAB COVID-19 Network Impacts Workshop 2020
- The Coronavirus disease (COVID-19) pandemic caused changes in Internet 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.
- RFC9095 - Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration
- This document describes an extension of Extensible Provisioning Protocol (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.
- RFC9102 - TLS DNSSEC Chain Extension
- This document describes an experimental TLS extension for the in-band transport of the complete set of records that can be validated by DNSSEC and that are needed to perform DNS-Based Authentication of Named 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.
- RFC9106 - Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications
- 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.
- RFC9120 - Nameservers for the Address and Routing Parameter Area ("arpa") Domain
- 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.
- RFC9138 - Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)
- 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).
- RFC9139 - Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)
- This document defines a convergence layer for Content-Centric Networking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4 Low-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 Networking Research Group (ICNRG).
- RFC9150 - TLS 1.3 Authentication and Integrity-Only Cipher Suites
- This document defines the use of cipher suites for TLS 1.3 based on Hashed 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.
- RFC9151 - Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3
- 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 or DTLS. 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.
- RFC9152 - Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients
- This document specifies protocol interfaces profiled by the United States National Security Agency (NSA) for National Security System (NSS) servers that provide public key certificates, Certificate Revocation Lists (CRLs), and symmetric keys to NSS clients. Servers that support these interfaces are referred to as Secure Object Delivery 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 (SP 800-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.
- RFC9170 - Long-Term Viability of Protocol Extension Mechanisms
- 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.
- RFC9180 - Hybrid Public Key Encryption
- 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 as Elliptic 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.
- RFC9187 - Sequence Number Extension for Windowed Protocols
- 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.
- RFC9188 - Generic Multi-Access (GMA) Encapsulation Protocol
- 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.
- RFC9189 - GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2
- 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.
- RFC9192 - Network Service Header (NSH) Fixed-Length Context Header Allocation
- The Network Service Header (NSH) specification defines two possible methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD Type 0x1 uses a fixed-length Context Header. The allocation of this Context 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.
- RFC9199 - Considerations for Large Authoritative DNS Server Operators
- 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.
- RFC9206 - Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec)
- The United States Government has published the National Security Agency's Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Internet Protocol Security (IPsec). It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59) that employ IPsec. 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.
- RFC9212 - Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)
- The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms with the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. It applies to the capabilities, configuration, and operation of all components of US National Security 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.
- RFC9215 - Using GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with the Internet X.509 Public Key Infrastructure
- 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 imply IETF endorsement of the cryptographic algorithms used in this document.
- RFC9217 - Current Open Questions in Path-Aware Networking
- 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 of 2021, 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.
- RFC9223 - Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE)
- The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol is specified for robust delivery of Application Objects, 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 multicast IP. 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.
- RFC9225 - Software Defects Considered Harmful
- 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.
- RFC9226 - Bioctal: Hexadecimal 2.0
- 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.
- RFC9227 - Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols
- This document defines a set of encryption transforms for use in the Encapsulating 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 R 34.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 imply IETF endorsement of the cryptographic algorithms used in this document.
- RFC9228 - Delivered-To Email Header Field
- 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 through SMTP'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 an Experimental RFC, looking for constituency and for operational utility. This document was produced through the Independent Submission Stream and was not subject to the IETF's approval process.
- RFC9230 - Oblivious DNS over HTTPS
- This document describes a protocol that allows clients to hide their IP 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.
- RFC9236 - Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service
- 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).
- RFC9238 - Loading Manufacturer Usage Description (MUD) URLs from QR Codes
- This informational document details a protocol to load Manufacturer Usage 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.
- RFC9265 - Forward Erasure Correction (FEC) Coding and Congestion Control in Transport
- 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 Network Communications 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.
- RFC9267 - Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing
- This memo describes common vulnerabilities related to Domain Name System (DNS) resource record (RR) processing as seen in several DNS client implementations. These vulnerabilities may lead to successful Denial-of-Service and Remote Code Execution attacks against the affected software. Where applicable, violations of RFC 1035 are mentioned.
- RFC9269 - Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks
- 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-Centric Networking (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.
- RFC9271 - Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses
- 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 Attachment Daemon 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.
- RFC9273 - Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges
- This document describes the current research outcomes in Network Coding (NC) for Content-Centric Networking (CCNx) / Named Data Networking (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 Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG).
- RFC9280 - RFC Editor Model (Version 3)
- 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 Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration 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 Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial 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.
- RFC9296 - ifStackTable for the Point-to-Point (P2P) Interface over a LAN Type: Definition and Examples
- 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.
- RFC9307 - Report from the IAB Workshop on Analyzing IETF Data (AID) 2021
- The "Show me the numbers: Workshop on Analyzing IETF Data (AID)" workshop was convened by the Internet Architecture Board (IAB) from November 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.
- RFC9315 - Intent-Based Networking - Concepts and Definitions
- 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 Research Group (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.
- RFC9316 - Intent Classification
- 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 Research Group (NMRG).
- RFC9318 - IAB Workshop Report: Measuring Network Quality for End-Users
- The Measuring Network Quality for End-Users workshop was held virtually by the Internet Architecture Board (IAB) on September 14-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.
- RFC9321 - Signature Validation Token
- 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.
- RFC9337 - Generating Password-Based Keys Using the GOST Algorithms
- This document specifies how to use "PKCS #5: Password-Based Cryptography 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 imply IETF endorsement of the cryptographic algorithms used here.
- RFC9340 - Architectural Principles for a Quantum Internet
- 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 Quantum Internet Research Group (QIRG).
- RFC9344 - CCNinfo: Discovering Content and Network Information in Content-Centric Networks
- This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-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 Networking Research Group (ICNRG). This document represents the consensus view of ICNRG and has been reviewed extensively by several members of the ICN 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.
- RFC9361 - ICANN Trademark Clearinghouse (TMCH) Functional Specifications
- This document describes the requirements, the architecture, and the interfaces between the ICANN Trademark Clearinghouse (TMCH) and Domain Name Registries, as well as between the ICANN TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods.
- RFC9367 - GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
- 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 Version 1.3.
- This document defines the cipher suites, signature schemes, and key exchange mechanisms for using Russian cryptographic standards, called GOST 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.
- RFC9380 - Hashing to Elliptic Curves
- 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.
- RFC9381 - Verifiable Random Functions (VRFs)
- 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.
- RFC9382 - SPAKE2, a Password-Authenticated Key Exchange
- 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 Internet Research Task Force (IRTF).
- RFC9383 - SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol
- This document describes SPAKE2+, a Password-Authenticated Key Exchange (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.
- RFC9385 - Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol Version 2 (IKEv2)
- 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 imply IETF endorsement of the cryptographic algorithms used in this document.
- RFC9401 - The Addition of the Death (DTH) Flag to TCP
- 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.
- RFC9402 - Concat Notation
- This document defines the Concat notation: a text-based language used to describe pictures and videos whose subject includes cats, containers, and their interactions.
- RFC9405 - AI Sarcasm Detection: Insult Your AI without Offending It
- 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.
- RFC9407 - Tetrys: An On-the-Fly Network Coding Protocol
- 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 NetWork Communications Research Group (NWCRG). It conforms to the NWCRG taxonomy described in RFC 8406.
- RFC9413 - Maintaining Robust Protocols
- 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.
- RFC9414 - Unfortunate History of Transient Numeric Identifiers
- 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 Assessments Research Group (PEARG) in the IRTF.
- RFC9415 - On the Generation of Transient Numeric Identifiers
- 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.
- RFC9419 - Considerations on Application - Network Collaboration Using Path Signals
- 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.
- RFC9426 - BATched Sparse (BATS) Coding Scheme for Multi-hop Data Transport
- 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 Efficient Network Communications Research Group (NWCRG).
- RFC9446 - Reflections on Ten Years Past the Snowden Revelations
- This memo contains the thoughts and recountings of events that transpired during and after the release of information about the United States National Security Agency (NSA) by Edward Snowden in 2013. 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.
- RFC9473 - A Vocabulary of Path Properties
- 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).
- RFC9474 - RSA Blind Signatures
- 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.
- RFC9477 - Complaint Feedback Loop Address Header
- 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 Message Originators 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 RFC Stream and was not subject to the IETF's approval process.
- RFC9490 - Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- The "Management Techniques in Encrypted Networks (M-TEN)" workshop was convened by the Internet Architecture Board (IAB) from 17 October 2022 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.
- RFC9496 - The ristretto255 and decaf448 Groups
- 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.
- RFC9497 - Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups
- An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of a Pseudorandom 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 a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
- RFC9498 - The GNU Name System
- 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 have IETF 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-existing GNUnet implementations).
- RFC9505 - A Survey of Worldwide Censorship Techniques
- 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.
- RFC9507 - Information-Centric Networking (ICN) Traceroute Protocol Specification
- This document presents the design of an Information-Centric Networking (ICN) Traceroute protocol. This includes the operation of both the client and the forwarder.
- This document is a product of the Information-Centric Networking Research Group (ICNRG) of the IRTF.
- RFC9508 - Information-Centric Networking (ICN) Ping Protocol Specification
- This document presents the design of an Information-Centric Networking (ICN) Ping protocol. It includes the operations of both the client and the forwarder.
- This document is a product of the Information-Centric Networking Research Group (ICNRG) of the IRTF.
- RFC9510 - Alternative Delta Time Encoding for Content-Centric Networking (CCNx) Using Compact Floating-Point Arithmetic
- 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 Networking Research Group (ICNRG).
- RFC9517 - A URN Namespace for the Data Documentation Initiative (DDI)
- This document describes the Namespace Identifier (NID) "ddi" for Uniform 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 Task Force (IETF) or Internet Society (ISOC). This Independent Submission is not a standard nor does it have IETF community consensus.
- RFC9518 - Centralization, Decentralization, and Internet Standards
- This document discusses aspects of centralization that relate to Internet 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.
- RFC9531 - Path Steering in Content-Centric Networking (CCNx) and Named Data Networking (NDN)
- Path steering is a mechanism to discover paths to the producers of Information-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 Data Networks" (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 Networking Research Group (ICNRG). It is not an IETF product and is not an Internet Standard.
- RFC9547 - Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022
- 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.
